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ABSTRACT 

The 1990 Naval Sea Systems Command Ship Design, Acquisition and Construction (DAC) Study provides a 
stepping stone for the implementation of improvements towards optimizing ship performance, cutting acquisition 
costs, and reducing design c>xle time. With respect to performance, significant ad\ ances in computing power 
coupled with customer oriented design (QFD, AHP, evolutionaiy^ optimization, etc) provide both impro\ ements and 
direct means to measure effectiveness of improvements. As for cost, implementation of world class building and 
design techniques (concurrent engineering, group tcchnolog>\ CAD/CAM/CAE, etc) coupled with higher fidcliW 
costing methods (ACEIT, POD AC, etc) provide sa\ings and direct measures of effectiveness. Cycle time 
improvements have also been implemented (IPTs, Open System Architecture, 3-D Product Models, etc). However, 
ship design managers have been unable to identify' and quantify’ design process effectiveness with respect to the 
impact of those proposed cycle time improvements. 

In order to understand the impact of cycle time improvements, it is necessary’ to examine the meclianisms 
w hich ha\ e lead to increased cycle time including external influences (such as increasing technological complexity 
and budgetary pressures), internal process delays (information flow delays and approval delays) and feedback 
processes (design iteratioa error propagation and design change.) Modeling of such meclianisms. using the 
methods of System Dynamics, prov ides a means to study^ past programs (in particular, the DDG-51 Destroyer 
program of the 1980's), and to study' the anticipated savings that can be generated with the introduction of process 
improvements. 

Of particular interest in modeling the naval ship design process w ith System Dynamics is the flow of design 
information. Traditional process analysis methods based on the design spiral represent tlie progression of design 
tasks as a linear process. However, actual design data propagation (a fundamental property’ resulting from the 
phy sical and architectural relationships of total ship sy stems) shows the process to be highly non-linear. These non- 
linearities are captured by’ system dy namics, providing a simulation tool tliat more fully captures the impacts of 
process improvements as they relate to the nav al ship design process. 

Thesis Supenisor: Alan J. Brown 

Title: Senior Lecturer, Department of Ocean Engineenng 
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1 Problem Statement 



In June 1 990, under the direction of Naval Sea Systems Command (NAVSE A) Chief Engineer, RADM 
Roger Horne, the United States Navy undertook a program to assess the effectiveness of the naval ship design, 
acquisition and construction (DAC) process. The focus of this project was “to identiiy the critical actions necessary 
to improve the quality' of future ship designs (i.e. meeting customer’s performance requirements), to reduce ship 
costs (from research and development through disposal), and to reduce the cycle time required from establishment of 
requirements to delivery of the lead ship.”^ It was immediately recognized that naval ship acquisition is itself 
unique within the constrained framework of the Department of Defense (DOD) and Department of the Navy (DON) 
organization. In particular, Navy ships are bought in small quantities, hav e very' long development cycles, and are 
extremely costly .. .precluding the “fly before you buy” approaches required for purchase of other weapon sv'stems.^ 
Additionally, the technical complexity' of warship design has passed the point that any “one” individual can be an 
“expert” in all aspects of the design.^ The resulting process is neither well documented nor well understood. 

Although the purpose for the DAC program was very wide-ranging, the specific reasons prompting the DAC 
effort were clear: increasing naval performance requirements are resulting in increasing ship costs and increasing 
cycle times for delivery^ The resulting ‘Affordability' Crisis”^ put strong pressure on the DOD to reform the 
acquisition process. Tliis “Crisis” is analy'zed by examining three key symptoms: increasing design cycle time, 
constraints leading to sub-optimal system performance, and increasing cost trends. 

1.1 “Affordability Crisis” 

1.1.1 Cycle Time 

The time required to conceptualize, design and produce new ship designs has been increasing steadily over 
the years. Consider the trends for naval combatant programs shown in Figure 1. Conceptual Design time (concept 
design and preliminary design) is increasing at a rate of 1 .5 months per year. Contract Award time (from program 
start through completion of contract design) is increasing at a rate of 3 months per year. Time to deliver completed 
sliips is increasing at a rate of 5 months per year. These trends are coupled witli exponentially increasing man-day 
efforts required to deliver sliip designs (Figure 1). Tliese trends are disturbing as they represent a barrier to 
providing warfigliters with timely systems necessary to meet threats. The causes of these trends are numerous and 
will be discussed in depth in Chapter 2. 



^ RADM Roger B. Home, “Concept to Commissioning: Ship Design, Acquisition and Construction Process 
Improvement Workshop IF, Richmond, VA, May 6-7, 1991. 

“ Ryan and Jons, “Improving the Ship Design, Acquisition and Construction Process”, Association of Scientists and 
Engineers, 28* Annual Technical Symposium, April 1 1, 1991. 

^ Tibbitts and Keane, “Making Design Everybody’s Job”, Naval Engineers Journal, May 1995, page 286. 

^ Timothy P McCue, “The Dy'namics of Naval Shipbuilding-a Systems Approach”, Department of Ocean 
Engineering Thesis, Massachusetts Institute of Technology', June 1997, pages 23-44. 
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Figure 1 Combatant Cycle Time Trends^ 

Tlie reaction to the DAC study and subsequent sliip programs since the realization of these trends was 
significant reform and ‘'modernization” of llie design process. Tliese reforms include revision of the basic 
Department of Defense (DoD) acquisition process requirements (Acquisition Reform), restructuring of the design 
organization to be inclusive of design agents, sliip constructors and customers (IPPD/IPT and Concurrent 
Engineering), and application of data processing advances (SBD and 3-D Product Models). 

One of the most significant process improv ements has come in the form of acquisition reform. Tliese refonns 
have been reahzcd primarily tlirough tlie introduction of DoDINST 5000-2R, the basic documentation of acquisition 
requirements. 

Another method of reducing cycle time, reducing cost and improving performance is the reform of design 
organizations. Consider the past approaches to nav al design. ^ In the 1950's, the Navy (namely the BuSliips) was 
responsible for complete design of ships and. in many cases, the construction of those designs at naval shipy ards. 
Tliis approach to “in-house” design and construction was appropriate and efficient because nav^al ships were 
relatively simple (designs were consistent with World War II technologies). Naval designs that were constructed by 
private shipyards were the result of a largely “non-adv ersarial” relationsliip between the Navy and industiy^. 

In 1960, the Secretary^ of Defense, Robert McNamara, introduced a new method of ship acquisition: Total 
Package Procurement (TPP). This transition was initiated to reduce costs and introduce system design of ships 
based on “ilities” (reliability, maintainability', survivability, etc.) Under TPP, the Navy independently perfonned 
concept foniiulation (CF) to validate operational requirements against potential ship designs, but the results were 
witliheld from industry'. Validated requirements (minus design suggestions) were “tlirowm ov er the wall” to 
industry', which performed independent contract definition (CD). CD established shipbuilder designs and solutions 

^ Ryan and Jons, “Improving the Ship Design, Acquisition and Construction Process”. Association of Scientists and 
Engineers, 28^ Annual Technical Symposium, 1 1 April 1991, page 10-11. 

^ Keane and Tibbitts, “A Revolution in Warship Design: Navy-Industry' Integrated Product Teams”. Journal of Ship 
Production . November 1996, page 255-259. 
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that optimized utilization of their construction facilities. Hovve\ er, the competitive environment prevented the Na\y 
from suggesting specific design desires, despite the fact that the Na\y retained responsibility for the majority of 
combat s\ stems to be integrated with the design. As a result, programs such as the LHA and DD-963 produced high 
quality ships^ (the result of industiy^ optimization of construction), but resulted in large cost o\ erruns (due to late 
design changes and GFE/GFI/GFM delays) and increasingly adv ersarial government-industrv^ relationships.^ As a 
result, TPP fell into disfavor. 

The programs of the 1970’s saw a return to “in-housc” design efforts b>' the Navy'. However, the decline of 
naval shipyards during the period of TPP resulted in the need to rely entirely on priv ate shipyards for construction. 
The newly formed Naval Sea Systems Command (NAVSEA) was responsible for all phases of design through 
contract award. The only inv olvement of shipbuilders was the performance of producibility’ studies to suggest 
largely generic improvements to the design. At the completion of contract design, the design specifications were 
awarded as a ship design support contract to a sliipyard which allowed lead ship detailed design to begin ev en while 
construction contracts were being negotiated The nature of the design process at this point allowed the Navy to 
retain significant, centralized control of the design througliout the life the acquisition. However, industrv was 
increasingly constrained by their late participation with the design, resulting in higher construction costs. 

The 1980's saw an attempt to bnng shipbuilders into the process sooner. During contract design, shipyards 
were invited to participate in the process as observ ers and to introduce extensive producibility' enhancements to tlie 
design. However, the potential shipbuilders could not achieve consensus on the design approach due to the 
substantial differences in their production methods and facilities. As such, NAVSEA designs adopted a “lowest 
common denominator ’ approach.^ Simultaneously, system integration issues (such as introduction of the Aegis 
Weapons Systems on CG-47 and DDG-5 1 class ships) became a dominant cost and requirements driv ers for ship 
optimization and design. The result w as the introduction of collocation of design agents and increased use of 
computer aided design (CAD). However, these efforts fell short of their goals. Centralized design control by 
NAVSEA meant that collocation for a single design project might jeopardize av ailability of design resources for 
other design projects. As for CAD, attempts to use a single product model sv stem meant translation errors and 
incompatibihties among as many as six different CAD s> stems in use by private shipyards. 

The lessons of 40 years of process methods are being applied in the 1 990’s in an attempt to reverse the cycle 
time trends. With downsizing of government organizations, NAVSEA is transitioning from centralized design 
control to design oversight. Acquisition reform, centered on the Federal Acquisition Streamlining Act (FASA), the 
Federal Acquisition Reform Act (FARA), and DoD Directive 5000. 1 (March 15, 1996)^^, prov ides a foundation 
from which government and industry' can mutually benefit in the design process. Specifically, these reforms are 



^ Keane and Tibbitts, “Naval Sliip Design in the 2 Centurv ”, Society of Nav al Architects and Marine Engineers, 
September 14-19 1993, page 19-3. 

^ Kenneth Cooper, Naval Ship Production: A Claim Settled and a Framework Built, Pugh-Roberts Associates. 
Cambridge, MA, December 6, 1980. 

^ Keane and Tibbitts, “A Revolution in Warship Design: Navy-lndustrv’ Integrated Product Teams”, Journal of Ship 
Production . November 1996, page 257. 

Refer to Chapter 8.3, Glossary and Abbreviations. 
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changing the timing of design transition from government to industry . Traditionally, the Navy controlled the design 
through contract award: at which lime CDRL’s, militarv specifications, and GFE/GFM/GFl were transferred to llie 
shipbuilder. This method left shipbuilders little room for producibility and design improv ements. This approach 
has changed under acquisition reform. Now, design responsibility is transferred to industry as early as possible, 
following or even during concept design. Instead of v eiy^ specific design requirements, current requests for proposal 
(RFP’s) prov ide industry with perfonnance specifications and concepts of operations aimed at coirmiunicating the 
nature of the problem to be solved., .not tlie solution. Tlie premise of reform is to allow industry to examine the 
needs of government and react to those needs with products not bounded by bureaucratic constraints or government 
design specifications. The goals are the reduction of government design and management overhead required for 
centralized design control and to provide industrv with the incentiv e to seek iimov ative solutions that take adv antage 
of technological and manufacturing strengths. 

From a cycle time view, acquisition refonn should reduce design time by setting specific schedules in the 
RFP for competing industries (as opposed to a single organization, the Navy, producing the design.) Tlius, failure of 
one entitv' to meet the timeline will result in their loss of the contract, not the lengthening of the process. 

Additionally, the transfer of the design earlier in the process will result in less total infonnation being transferred 
(tlius, less chance of error) and open lines of communication at a time when concepts and requirements arc much 
more negotiable. 

To facilitate acquisition reform, a number of specific process innovations are being incorporated. A primarv’ 
mechanism is the introduction of Integrated Product and Process Dev elopment (IPPD)/lntegrated Product Teams 
(IPT) By IPPD/IPT, multi-disciplinar\’ teams (representation of all potential elements of design and production 
with customer participation is mandatorv ) examine all aspects of the design process (requirements, technologv' 
alternatives, cost, ILS, manmng, etc) in an environment that promotes communication. The metliodology builds on 
the notion that no single person is the ultimate expert. Wliether actual or virtual, collocation is critical to tlie 
process. Integral to IPPD/IPT is concurrent engineering'^. Conciurent engineering seeks to consider all life-cycle 
aspects from the earliest design stages Ihrougli manufacturing, deployment, operations and disposal. These 
techniques apply some basic principles; process orientation, team approach, empowennent, and open 
communications, parallel development and customer satisfaction. Cycle time should be shortened as critical issues 
for production and support as well as pro's and con’s of design options are resolved early in the process, when 
rework and design disruption do not impact the process as greatly. 

In addition to team and process approaches, the design cycle is being improved by the introduction of 
improv ed data management and analysis. The use of 3D Product Modeling'^ seeks to integrate 3D geomelrv'. 
associativ e and parametric relationsliips and non-geometric information into a single model to be employed from 
concept design through ultimate ship disposal The model acts as the repository^ for ship design and production 

" Sinmions, Assessment of Options for Enliancing Surface Ship Acquisition, Institute for Defense Analyses. March 
1996, pg. 39-40. 

Baum and Ramakrishnan, "Applying 3D Product modeling Technologv^ to Shipbuilding”, Marine Teclmologw 
Januarv 1997, pg. 56. 
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informatioru and integration of logistics and life-cycle data. The model facilitates inputs and outputs for all design 
analysis including cost and mission effectiveness, engineering assessment and producibility. An example of a 
generic product model is shown in Figure 2. The model enables virtual en\ironment design re\iew s, virtual 
shipvurds, and simulation-based design. Non-geometric data is placed in a relational database svstem. 3D solids 
and surfaces are defined once with geometiy modeling and parametrics and linked to multiple locations with an 
associativity feature. The design is stored in a heterogeneous distributed database managed by a relational database 
product data manager (PDM). Users establish design rules (analysis tools, design parameters, constraints) fi-om 
which the design is automatically generated. . .when rule violations occur, the user is notified and prompted to 
resolve conflicts. Ultimately, a series of 3D Product Models for various ship designs could form a “Knowledge 
Base’' from which future designs could be rapidly dev eloped. 




A key feature of a 3D product model is the capability to facilitate Simulation-Based Design (SBD)^*^. SBD 
allows designers to assess technologv^ insertion and design concepts in the virtual environment using Virtual Reality 
(VR), very large complex database sv stems. optimization techniques, complex data visualization. Artificial 
Intelligence (AI) and liigh performance networking. SBD realizes cost sav ings and performance enhancements 
tlirough Modeling and Simulation (M&S) of design options (vice physical prototype construction) followed by 
direct extraction of production instructions (C AD/C AM/C AE^^) from virtually tested designs. When fully realized, 
3D modeling and SBD will allow dynamic model interactions of design parameters among the major design 
participants (Program Manager. Mission Analyst, Nav’al Arcliitect, Mechanical Specialist. Purchasing Agent. 
Arrangement Specialist. Structural Specialist, Production Specialist, Operational Personnel, Manufacturing 
Specialist), and utilize these relationships to perform all required concept analysis (Mission Analv sis, Mechanical 
Svstem Analysis, Sliip Arrangement Scenario. Operational Simulation, Coupled Hydrodynamic/Structural Analv sis, 



Ibid., pg. 56-65. 

Polini, Wooley, Butler, “Impact of Simulation-Based Design on Today's Shipbuilders”, Marine Technology , 
Januaiy^ 1997, pg. 1-9. 

Tibbitts and Keane, “Making Design Evervbodv 's Job". Nav al Engineers Journal, May 1995, page 283. 
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Manufacturing Simulation, and Cost Analysis) in a virtual em ironmcnt. The impact on design cy cle time should be 
the ability to rapidly test design concepts and resolve design concerns prior to expenditure of time and resources on 
physical protot>pes. 

Tliese reforms, though certainly more refined, are not entirely without precedence. Early design hand-off was 
first used during TPP. IPPD mcthodolog>' was implemented during the 1970’s for tlie FFG-7 program. Collocation 
and CAD technology was implemented during the DDG-51 and CG-47 programs. Total s\’steni trade-offs of cost 
and performance have been in use to \ ary ing degrees for several decades. Thus, the issue is now one of how much 
of each reform to implement, how will implementation impact ultimate performance and cost, and will external 
forces negate the gains brought about by reforms? 

These questions are especially important in hght of the long duration of design programs. For instance, 
typical dmations for combatant sliips can exceed 12 years: Upical weapons s> stem programs require 15 years for the 
production item, and official DoD timelines (satisfying all program requirements) can exceed 22 years.’^ Those 
programs that have undergone the reforms of the last 10 years hav e yet to produce quantitative results satisfactory’ 
for analysis of improvement effectiveness: ‘‘There are good, although anecdotal, examples of this foundation 
actually being propagated in the field for our major programs.^ " Is there a way to test and optimize impro\ ements 
prior to implementation? 

Consider the traditional project management methods listed in Tabic 1. These methods focus primarily on 
operational issues necessary to define project work structure, resource availability and requirements, and budget 
requirements and allocations. Tlie methods are becoming increasingly mature w ith de\ elopment of software suites 
like Microsoft Project®, At-Risk® and DoD ICOM (Input, Constraint, Output and Mechanism) packages. The 
approaches assume a well ordered project that progresses in well-defined stages to completion. In particular, the 
techniques assume a linear, or, in the case of PERT/ICOM, limited feedback process. Process improvements can be 
intimated and assessed by examining the risk-benefit of options or by in depth analysis of Critical Paths in the 
process. How ever, this analysis often fails to detect systemic impacts of a giv en process improvement or realize 
strategic goals for improvement processes. At issue is the inability of these methods to capture decision process 
logic, political/social factors, workplace environment and other human factors. Additionally , their static nature 
cannot capture d\ namics like schedule pressure, workforce experience shifts or rew ork issues. System ch namics 
can provide a methodology’ to capture these issues and provide the strategic analysis necessary^ to optimize process 
improvements. 



Ryan and Jons, “Improving the Ship Design, Acquisition and Construction Process", Association of Scientists and 
Engineers. 28^ Annual Technical Symposium. 1 1 Apnl 1991, page 11. 

^ Dr. Paul Kaminski, Under Secretary’ of Defense (Acquisition and Technology ), inten iew in Program Manager , 
January-February’ 1997, page 12. 

Rodrigues and Bowers, “System Dynamics in project management: a comparative analysis with traditional 
methods". System Dynamics Review’ , Volume 12 number 2. Summer 1996. page 124. 
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Technique/Tool 


Purpose 


Work Breakdown Structure (WBS) 


Basic definition of the project work. Precedes the 
project schedule and cost estimates 


Gantt Charts 


Representation of project schedule, may show' 
simple precedence relationships 


Project Network Techniques; PERT. CPM. PDM, 
GERT 


Analysis of scheduling impacts based on precedence 
relationships, cost estimatioa resource allocation, 
management and risk analysis, and input -output 
relationships 


Dynamic Strategic Plamiing (DSP) 


Cost benefit analysis incorporating risk 
relationships of net present value (NPV) for options 
against the customer utility' for those options 



Table 1 Traditional Project Management Techiques^^® 



System dynamics has been successfully applied to strategic project management for many decades. Since 
1964, dynamic models ha\ e been applied to projects ranging from naval construction (1980 Litton-lngalls 
Shipbuilding Litigation model) to large-scale DoD software de\ elopment projects."^ Tliese models have accurately 
identified key causes of process degradation including interdependencies created by process concurrence, impacts of 
project scope change, and relationship of schedule pressure to producti\ity. 

Recently, several chmamic models ha\ e been created to address the issue of strategic process improvement in 
private shipyards. The McCue Production Model (MIT 1 997"") demonstrated the impact of manpower fluctuations 
on producti\ it> and cost for Bath Iron Works and Ingalls Sliipyard. The focus of the McCue model on manpow er 
loading pro\ides tremendous insight into tlie necessiU' to maintain w orkforce levels, even in light of short-term 
economic loss, in order to maintain the agility necessaiy to compete for emergent contracts. Tlie Simulation of New 
Acquisition Processes (SNAP) program (DDl 1997"^) bridges the gap between s>'sleni dynamics models and 
operational methods b\‘ demonstrating the dynamic flow of ship\ ard work against changing resource availabiliU’, 
persomiel productivity and schedule pressure. Tlie model is especially useful because it incorporates ship work 
breakdow n structures familiar to shipyard managers. . . thus, instilling a higli level of confidence in tlie results of 
process anah sis. Models are also being applied to other na\ al process issues such as operations and support costs. 



Ibid., page 121. 

Richard de Neufv ille, Applied Systems Analysis: Engineering Planning and Technology^ Management . McGraw- 
Hill Inc, 1990. 

Rodrigues and Bowers, “System D> namics in project management: a comparath e analysis with traditional 
methods'’. System Dynamics Rc\iew , Volume 12 number 2, Summer 1996, page 128. 

"" Timothy McCue. 'The D> namics of Na\ al Shipbuilding-a Systems Approach", Tliesis for Massachusetts Institute 
of Technology, June 1997, 

Alfeld, Wilkins and Pilliod. "The Virtual Shipyard; A Simulation Model of the Shipbuilding Process", The 
Society of Naval Architects and Marine Engineers. April 21-23, 1997. 
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naval forces requirements and cost optimization*'^, and the interaction of DoD acquisition programs*^. The effect of 
this effort is the increased application of system dynamics as a tool to assess and optimize process improvements 
from the strategic level. However, there has not yet been a significant move to apply simulation models to the 
design process. 

A, Unacceptable cycle time trends have lead design managers to implement many process 
improvements aimed at reversing these trends. However^ insufficient time has passed to determine the 
full effectiveness of these improvements, 

B, Given the duration of the design process and the lack of fidelity in traditional project management 
methods to strategically analyze effectiveness j system dynamics should be applied to naval design to 
provide a means of: 

1, Analyzing the causes of cycle time gronth 

2, Gaming*' potential process changes to determine effectiveness and relative risks. 



1.1.2 Requirements and Design Performance 

Like the problem of cycle time trends, performance issues are an increasing concern to w arfighters and 
designers alike. Requirements assessment is seeing significant introduction of new techniques to assess risk and 
effectiveness long before the laying of steel or the programming of weapons software. 

‘The modem warship (is the) most complex machine devised by man."*^ Their complexity crosses e\ er>' 
discipline of modem engineering and physics from fluid dynamics to computer network design to nuclear 
engineering. The complexiK is further increased by the dynamic interactions of these unique disciplines resulting in 
the integration of a single system. The ad hoc optimization process, which creates this sy stem, is based on 
compromise and tradc-off of \ arious requirements and system options. However, with ever grow ing design 
complexity comes an increasingly unanswerable question: has the optimal solution been achie\ cd? Resoundingly, 
the answer is no, and the difficulty is translating operationally required mission effectiveness into optimized design 
parameters. 

Until recently, mission effectiveness was defined qualitatively. Performance requirements were pro\'ided to 
designers, but the operators had few means to quantitatively assess the effectiveness of such requirements, and 
designers were provided little room or guidance to trade requirements and cost. For example, requirements would 



Towles, Rocholl, Jeffers and Platt, “Force Affordability Modeling; the EH namic Im estmcnt Balance Simulation 
(DIBS)", presentation to Naval Surface Warfare Center (Tarderock Division, Bethesda. MD, April 15, 1997. 

Towles, Rocholl, Jones, Jeffers and Platt, “System Womiliole Analysis Tool (SWAT): a Simulation Based 
Acquisition Initiative," presentation to Na\ al Surface Warfare Center Carderock DiMsion, Bethesda, MD, October 
27, 1997. 

Gale and Scott. "Early Stage Ship Design Seminar", Society of Naval Architects and Marine Engineers, October 
1995. 
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state “cany out anti-submarine operations in the North Atlantic^’ or "maintain X knots in sea state 5.’'“ Such 
statements are misleading to both requirements setters and designers. The first, more general statement, does not 
indicate any level of trade-off or even a notion of what “anti-submarine operations” might entail. The designer is 
forced to assume an engineering definition and may inevitably misinterpret the operators' true intentions. The 
second, more specific requirement remov es all potential for tradc-off against other variables, and does not allow 
alternate solutions to tlie problem. Under these circumstances, designers are often detached from customers 
(operators), and are forced to make critical decisions without explicit feedback until the sv stem is operational. 

For the designers, there is a lack of clariU’ as to who the customer is:"^ the operator, the sliip builder or just 
the next designer in the design chain. There is a tendency to under-fund R&D efforts and requirements setting 
processes which would allow both designers and operators to reach better optimized solutions. Tliese factors 
combine to add confusion and delays to the requirements setting process. 

Requirements setters within the operating forces of the Navy (OPNAV), are frequently focused on details and 
fail to communicate “big picture” needs. Turnov er is also rapid and OPNAV personnel may be transferred before 
they understand and appreciate the problem.“^ Additionally, the customer lacks understanding of the ship design 
process. Specifically, the fleet operators aren't able to understand how specific requests for performance translate 
into design trade-offs. 

When performance changes are requested (due primarily to out-of phase dev elopment programs and 
conflicting requirements at v arious stages of design definition^^), the resulting disruption to the design process is 
significant. For instance. Table 2 shows how design priorities changed over the course of the DDG-51 preliminarv^ 
design effort. Customer prioritv' changes, particularly with respect to energv’ conservation, resulted in a large design 
effort (culminating in several design variants and two independent design studies^") to analv-ze designs vviiich 
incorporated the RACER (Rankine Cycle Energy Recover} ) propulsion sv stem. However, total ship sv stem impacts 
of RACER and program risks related to the RACER R&D schedule (not in phase with DDG-5 1) ultimately resulted 
in cancellation of the RACER integration with DDG-51 and a further realignment of performance priorities (highest 
to lowest) in the DDG-51 contract phase to^^ 

a. Combat sv stem capability 

b. Speed and endurance 

c. Survivability’ 

d. Habitability’ 



Dav id Brown. “Naval Arcliitccture”. Naval Engineers Joiunal . Januaiy 1993, page 43. 

Ibid, page 2-22. 

Roger Home, Improving the Ship Design, Acquisition and Construction Process: Stratede Plan , Naval Sea 
Systems Command, Washington DC, June 1991, page 2-20. 

Ibid, page 2-21. 

Ibid, page 2-21. 

Andy Summers, , PPG 51 Guided Missile Destroyer Preliminary Design Historv’ , Naval Sea Systems Command. 
June 1984, page B-1, 

Andy Summers, PPG 51 Guided Missile Destroyer Contract Design Historv , Naval Sea Systems Command June 
1987, page 3-1. 



14 



e. Design flexibility and growlh potential 

These changes lead to further delays and generated additional iterations of the DDG-5 1 design. Changing 
prionties, unclear requirements relative to total s> stem impacts and out of phase dc\ elopment programs generate 
design effort. 



Attribute 


Priority at Start 


Priority at Finish 


Combat Capabihty 


High 


High 


Acquisition Cost 


High 


Medium High 


Operability 


Medium Higli 


Medium 


Passive Survivability^ 


Medium High 


High 


Energy Conserv^ation 


Medium High 


High 


Future Growth Flexibility 


Medium High 


Low 


Active Survivability 


Medium 


Medium Higli 


Ship Displacement 


Medium 


High 


Manning Reductions 


Medium 


Low 


Habitability 


Low 


Medium High 


Minimum Risk 


Low 


Low 


Standardization 


Low 


Low 



Table 2 Preliminarx Design Priorities at Beginning and End of Design Phase^^ 

As a result of the noted shortcomings (dating back to tlie late 1980's), the DAC study^^ and other process 
improvement efforts such as Secretary' of the Navy Instruction 5000.2B^ , tlie requirements process now institutes 
improved performance assessment mechanisms. Tliese mechanisms provide for structured input of requirements, 
assessment of engineering solutions with respect to those requirements and feedback from operators regarding 
sv stem solution options. Some of these improv ed methods include Qualitv’ Function Deployment (QFD), Analvlical 
Hierarchy Process (AHP), and Genetic Algorithms.^^ 

The QFD method, vv hich was devised by a shipvard in Kobe. Japan to address the same problems relative to 
Its customers, provides a structured process of taking customer needs (stated in the subjective, qualitative and non- 
technical '‘v oice of the customer") and translating those needs into “corporate language" (quantitative and technical 



Verne Stortz, “DDG-5 1 Cost Estimate Log", Nav al Surface Waifare Center Carderock Div ision, Bethesda. MD. 
October 1984 

Andy Summers. , PPG 51 Guided Missile Destroyer Preliminary Design History , Naval Sea Systems Command 
Jime 1984, page 3-1 and 3-3. 

Ibid, page 2-16. 

John Dalton, Implementation of Mandatory^ Procedures for Major and Non-Maior Defense Acquisition Programs 
and Major and Non-Major Information Technology Acquisition Programs (SECNAVINST 5000.2B) , Department of 
the Navy, Washington DC, December 6, 1996. Appendix II. 

Defense Acquisition Deskbook Joint Program Office, “Defense Acquisition Dcskbook Version 2.3. 101", Wright- 
Patterson Air Force Base, Ohio, March 31, 1998. 
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parameters required by designers. The customer traits are commonly referred to as Measures of Effectiveness 
(MOEs) while design performance attnbutes are Measures of Performance (MOPs). QFD pro\ides a qualitative 
mapping from MOEs to MOPs. The two ‘‘languages” are translated \ia a matrix referred to as the “House of 
Qualin” (see Figure 3 below.) Tlie mapping highhghts s>nergies and conflicts between design options and 
competing customer requirements. As a result, customers and designers can visualize design trade-offs and propose 
alternative solutions. The process is iterative and its greatest use is as a means to facilitate communication between 



customers and engineers througlioiit tlie design process. The metliod has proven useful in Na\y programs ranging 
from tlie Joint Advanced Strike technolog>^ (JAST) program to the Next Generation Carrier Program (CVX.)*^^ 




Figure 3 Quality Function Deployment "House of Quality"^^ 



Tibbitts and Keane, “Making Design Everybody's Job”, Naval Engineers Journal. Mav 1995 , page 287. 
Ibid, page 287. 

International TechneGroup Incorporated (ITI), http://\v\\w iti-oh.com/cppd/qfd/qsoft.htm. 
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Whereas QFD is a qualitative method of communicating performance attributes. AHP aims to quantifS’ 
perfonnance attributes in a manner which allows designers to search a boarder solution space while still meeting 
fundamental performance needs. Specifically, requirement setters and engineers establish a well defined mutually 
agreed to set of performance attributes and tlie quantifiable values of those attributes. The requirement setters then 
w eight tlie attributes tlirough a series of pair-wise comparisons. The result of such comparison is a vector of 
weigliting factors relating the '‘goodness” of each attribute against another. Thus, engineers can explore the entire 
solution space and determine the optimization of customer needs within that space. An example of this method of 
has been to quantify variables ranging from producibilit}’ of ships to life-cycle cost to combat perfonnance.^^ In this 
example, subject-matter experts were questioned regarding a number of performance attributes. Those attributes as 
well as the weighting factors for a number of ship t>pes (Destroyers and Carriers) are shown in Table 3 below. 

Using the AHP method, a designer would 

a measure the attribute values (MOPs) for generated s\ stem designs (such as sustained speed is 20. 1 
knots or 25.6 knots), 

b. normalize the MOPs against previously agreed goal and tlireshold \ alues (such as 20. 1 is 0.0 14 and 25.6 
is 0.80 to a goal of 27 knots and a threshold of 20 knots) or ask customers to re-evaluate design 
attributes directly by additional pair-wise comparison (to generate a summaiy^ values from 0 to 1 for a 
parameter hke modularity), 

c. multiply normalized MOPs times the weightings for each parameter which in turn generates top-le\ el 
MOEs for each attnbute category (such as 0.8 times 0.3 174 is 0.2539 for speed and the total of all MOPs 
for Operational Capability adding to a value such as 0. 1 12), 

d. then sum the MOEs to determine an 0\ erall Measure of Effectiveness (OMOE) value for each design 
(such as design 1 is 0.23 and design 2 is 0.45)... the liighest OMOE design is the optimal customer 
directed design relative to the other scored designs. 



Wilkins. Kraine and Thompson. “Evaluating the Producibility^ of Ship Design Alternatives". Journal of Ship 
Production, August 1 993, page 1 96-20 1 . 
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Ship Performance Criteria 


DD 


CVN 


Operational Capabilitv^ 


0.5971 


.07009 


Payload Carrving Capacitv' 


0.1293 


0.0666 


Payload Effectiveness 


0.3030 


0.3252 


MobiliW 


0.1194 


0.0362 


Speed 


0.3174 


0.4444 


Endurance 


0.5110 


0.4444 


Maneuverability' 


0.1716 


0.1111 


Availability' 


0.2516 


0.1814 


Survivability' 


0.1967 


0.3907 


Operational Efficiency 


0.2106 


0.2020 


Manning 


0.3768 


0.7142 


Habitability' 


0.2066 


0.1429 


Safety 


0.4166 


0.1429 


Future Growth Margin 


0.1924 


0.0971 


Weight Margin 


0.2460 


0.3214 


KG Margin 


0.1582 


0.3214 


Volume Margin (density) 


0.2060 


0.3214 


Modularity 


0.3898 


0.0357 



Table 3 Ship Performance Weighed by Analytical Hierarchy Process Methodology‘S^ 

The previous methods provide both a means to define customer needs relative to designer attributes and 
trade-off specific designs against each other in a structured environment. Genetic algorithms provide the fmal step 
in s>'stem performance optimization by systematically enabling designers to search a liiglily non-hnear design space 
for tlie overall optimal solution relative to the user defined OMOE. Specifically, genetic algorithms take a series of 
design parameters or “genetic materials" (such as LBP, a series of discrete combat systems suites or various hull 
material mixes), generate designs from those genes, assess the OMOEs for the resulting designs, “mate" tlie designs 
with each other to generate new “generations" of designs, introduces “mutations" to a limited number of the genes in 
each generation, and continues the process until the design no longer improv es or “evolves." Traditional AoA 
melliodologv^ derives optimization of the design space tlirough directed exploration of an overlv' large number of 
design alternatives. Such exploration is only possible using design svuthesis tools like the Adv anced Surface Ship 
Evaluation Tool (ASSET). Such tools allow a small team of designers to rapidly develop and balance a large 
number of sliip alternatives. For example, the current CVX program is e.xploring design in three stages (airwing size 
and composition alternatives, propulsion alternatives and s>slem alternatives) with as many as 30 designs per stage. 
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Ibid, page 200. 
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Past explorations using design synthesis programs like DD08 and ASSET ha\ e generated as man\' as 1000 different 
ship designs in an effort to ensure an optimum solution.*^^ However, e\ en with s\Tithesis tools, much the design 
work is still manual, such as topside arrangement of a combat s\ stem suite or flight deck design in a CAD 
environment. As such, designers still must approach tlie analysis of the solution space as an “experimental design”, 
which is linear. Given the increasing complexity’ of current designs and the time required to generate a single 
design, it is necessary to have a method like genetic algorithms to ensure not only local, but global optimization of 
the solution. As the design space is highly non-linear, sub-optimized solutions are often pursued (see Figure 4.) 
Genetic algorithms can avoid such occurrences by not focusing the search in a linear manner (as with by a staged 
AoA approach) but evolving beyond local optima to achieve the peak solution. The use of such approaches are 
proving successful both in academic pursuits of design (Mark Tliomas and Allan Andrew theses) and activ e 
programs (Joint Strike Fighter Program use of SNAP^^). 

Performance and the sy stematic optimization of performance is a key concern to operators and designers 
alike. However, the customer oriented methods of QFD and AHP, along with the optimization techniques of AHP 
and Genetic Algorithms, provide means to ov ercome past concerns. The Navy is beginning to apply these 
techniques with success. . .but the question remains whether these successes are enhancements to design performance 
alone, or whether the dy namic impacts of performance enhancements will result in cost and cycle time growth. 

These impacts will be addressed further in Chapter 2. 



Myron Ricketts, Manual for Naval Surface Ship Design Technical Practices . Nav al Sea Systems Command 
Washington DC, 1980, Volume 1, page 5-35. 

Alfeld and Shepard, “SNAP-Simulating New Acquisition Processes". CAIV Workshop. Decision Dy namics INC, 
11-12 July 1997. 
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Evolutionary Strategies 
will find the best solution 
within the solution space 



Multiple Local Optima 

Large Flat Areas 

Non-optimal solutions 

Even when the 
landscape changes 



Figure 4 Optimization and Genetic Algorithms^* 



1.1.3 Cost 

In addition to the need to achieve required performance within a constrained schedule, modem warships must 
also be cost effecti\ e. The cost of ships has been steadily increasing, well above obvious increases due to inflation. 
The DAC stud\^ shows an alanning growth trend. Average combatant ship acquisition cost in equiv alent dollars 
(nonnalizxd in the stud\^ to Pf 90) has increased linearly over 800% per vessel over a thirty year period."*^ This trend 
alone, has represented the single most critical factor driving the need for acquisition refonn. As such, strategic cost 
analysis and cost analysis tools hav e received sigmficant emphasis in the last decade. 

There are a multitude of reasons for this trend. Consider the list of cost roadblocks disclosed during the DAC 
Study (Table 4). Many of the listed concerns (constmetion delays from late design changes and GFE/GFI, lack of 
shipbuilder producibilit>* inputs, and failure to fully explore design options prior to preliminar\' and contract design) 
ha\ e already been noted as equal problems related to schedule and perfoniiance. 



Ibid. 

Ryan and Jons, “Improving the Ship Design, Acquisition and Construction Process’, Association of Scientists and 
Engineers, 28* Aimiial Technical Svmposiuin, 1 1 April 1991, page 11. 
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• Too many changes after contract award 

• Requirements setting without rigorous cost-benefit analysis 

• Lack of cost awareness or cost analysis capabiliK organic to the design communit\^ 

• Inefficient shipbuilding practices 

• Awards based on unrealistic, low bids 

• Late delh er>' of GFI/GFE 

• Labor intensive ship designs 

• Insufficient production and future growth margins 

• Lack of system architecture to accept change 

• Out dated specifications, practices and margins 

• Under-funding of Concept Design Phases 

• Increasing complexity and cost of combat systems 

• Excessive costs associated w ith prograrmnatic documentation 

Table 4 DAC Study Cost Roadblocks^^ 

The most noteworthy cause of cost growth in naval design is the failure to leverage the relationship betw een 
cost and time. Consider Figure 5. In the early stages of design, decisions are made that define the general 
characteristics of the sliip. Those initial decisions hav e not traditionally incurred large costs (i.e. concept design 
funding has been hmited), but they do produce future costs by the definition of specific sliip design choices. For 
example, the result of concept design may indicate the desired vessel to be a destroyer, approximately 465 ft long, 
6800 Iton hglit ship displacement, capable of 30 kts sustained speed using 4 LM-2500 engines, with 350 personnel, 

1 5’754 DP Gun, 96 VLS cells and the Aegis weapon s>stem centered aroimd the SPY- ID radar svstem. The 
description does not provide enough detail to construct a ship, but it is good enough to estimate acquisition cost to 
within 80% probabiliW of accuraev'. The reason is that historically, the above factors will result in 80% of the total 
cost of the ship. As the design process matures, greater design detail is expressed, incurring greater costs through 
increased design effort and ultimately, construction. However, this detail does not create substantial changes in end 
cost. For our example, later design stages may change the length to 466 ft, the deckhouse may be constructed from 
steel vice aluminum, and the scantlings in the double bottom may be increased for increased defense from 
underwater explosions. Hovvev'er, these changes will not result m significant cost changes beyond the initial 
estimate. This fact will be increasingly important with respect to combat system impacts on cost (discussed below). 
Tlius, the levels of cost "lock-in" and cost inciured are inv ersely proportional. 
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Figure 5 Kev Transitions in the Design Process 

This relationsliip can be further demonstrated in the methods of managing vveiglit and weight based costs 
during the design process. Consider a typical trend for weight and KG demonstrated in Figure 6. Despite short-term 
fluctuations, the overall trend (indicated by the included trend line) is that of exponentially deca\ ing growth towards 
a final value, namely, the light sliip weight at launch. It is necessary' that convergent behavior in all aspects of the 
naval design exist. Otherwise, it would be impossible to detennine whether the completed ship would function 
desirably as a s\ stem (i.e. float and float upriglit.) It is likewise expected that tlie values for properties such as 
weight. KG, electrical load, etc. at the beginning of contract design will be exceeded during detailed design: and 
even further exceeded during the expected life of the ship. As the design matures, assumptions regarding sy stem 
weights, locations, scale, etc, arc refined. To err conservatively, the assumptions are adjusted with margins to reflect 
potential growth. Margins arc added to those system v alues (weight. KG, powering, etc.) that are critical to ship 
performance. Table 5 shows weight and KG margins used for the design naval surface combatants. These margins 
are considered the minimum additional weight or moment-arm that should be included in a design to account for 
uncertainty in assumptions. At the conclusion of a design phase, the design managers may choose to reduce or 
eliminate margins from previous stages as the level of confidence in the current design values (reflectiv e of the lev el 
of detail achieved) is increased. This trend is displayed for the DDG-51 program in Figure 7. 
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Weightand KG Trends 




Figure 6 DDG-51 Contract - Detailed Design Weight and KG Trends^^ 



Weight and Weight Margin Trends 




Figure 7 DDG-51 Detailed Design Weight Margin Trends^^ 



Mike Jeffers. Inler\ ie\v at Naval Surface Warfare Center Carderock Division. Bethesda, MD, No\ ember 12. 1997. 
Ibid 
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Weight Margin 


Mean % 


Mean Plus Standard Deviation % 


PD/CD Margin 


0.83 


4.36 


D&B Margin 


1.71 


5.29 


C. MOD Margin 


0.33 


1.43 


GFM Margin 


0.33 


1.20 






12.28% 


KG Margin 






PD/CD Margin 


2.67 


6.09 


D&B Margin 


1.87 


4.97 


C. MOD Margin 


0.18 


1.12 


GFM Margin 


0 


0.34 






12.52% 



Table 5 NAVSEA Design and Life Cycle Margins^' 



As regards cost, it is important to consider the trends of design resulting from margins and convergent design 
because the traditional methods of determining cost rely hea\ ily on w eight and major system selections. 

Specifically, traditional acquisition cost estimates during design are determined using parametric analysis of weights 
(from Sliips Work Breakdow n Structure (SWBS) groups) for similar ship t}pes of the past. Table 7 show s top-level 
SWBS groups considered in early ship design and cost analysis. Tlie SWBS groups represent an accounting method 
tliat prov ides means to estimate features of the ship (such as w eiglits and distribution of weights for structures, 
support S} stems, etc) tliat caimot be explicitly defined during early design. Cost estimating relationships (CER's) are 
applied to the SWBS w eights to determine cost estimates. These w eight-based cost estimates may be adjusted for 
specific shipyards, known s> stem costs, learning curves associated with multi-year contracts (Figure 9), and other 
reasonable cost impacts. Generally, the result of the estimates determined in this mamier should follow behavior 
similar to the weight behavior of Figure 6, i.e. the estimate should conv erge. During later design stages, small 
transfers of w eight from one SWBS group to another iv \y result in substantial first order cost impacts. These 
impacts can be forecasted early in the design process througli sensitivity analysis of the parametrics (Table 6.) 

How ever, the second order cost impacts due to disruption, transitions within SWBS groups and multi-ship schedule 
shifts are not disclosed with weight-based costing^^. Although these impacts are usually v\ ithin 20% of the 
parametrically determined values, they can grow to lev els of well over the initial cost.^^ That has been a criticism of 
such cost methods. There is a need to improv e the methodology of weight-based costing to be responsiv e to second 
order effects, or new methods must be used. 



Reuven Leopold, Manual for Nav al Surface Ship Design Technical Practices , Naval Sea Systems Command, 
Waslungton DC, 1978, page 4-157 

Kenneth Cooper, Naval Ship Production: A Claim Settled and a Framework Built, Pugh-Roberts Associates, 
Cambridge, MA, December 6, 1980. 

Prof Alan Brown, interview May 11, 1998, Massachusetts Institute of Technologv, Cambridge, MA. 
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Ship Work Breakdown 
Structure 


Program Cost 
(FY 83 S/lton) 


100 Structure 


17,500 


200 Propulsion 


110,800 


300 Electric 


180,200 


400 Command 


46,300 


500 Auxiliary 


80,800 


600 Outfit 


78,500 


700 Armament 


16,000 



Table 6 CostAVeight Sensiti\ity^‘* 



SWBS 


Description 


SWBS 


Description 


100 


Hull Structures 


500 


Auxiliary Systems, General 


110 


Shell and Supporting Structure 


510 


Climate Control 


120 


Hull Structural Bulkheads 


520 


Sea Water Systems 


130 


Hull Decks 


530 


Fresh Water Systems 


140 


Hull Platforms And Flats 


540 


Fuels and Lubricants.Handling and Storage 


150 


Deck House Structure 


550 


Air. Gas and Misc Fluid Systems 


160 


Special Structures 


560 


Ship Control Systems 


170 


Masts. Kingposts. And Service Platforms 


570 


Underway Replenishment Systems 


180 


Foundations 


580 


Mechanical Handling Systems 


190 


Special Purpose Systems 


590 


Special Purpose Systems 










200 


Propulsion Plant 


600 


Outfit and Furnishings, General 


210 


Energy Generating System (Nuclear) 


610 


Ship Fittings 


220 


Energy Generating System (Nonnuc) 


620 


Hull Compartmentation 


230 


Propulsion Units 


630 


Preservatives and Coverings 


240 


Transmission and Propulsor Systems 


640 


Living Spaces 


250 


Propulsion Support Systems (Except Fuel and Lube Oil) 


650 


Service Spaces 


260 


Propulsion Support Systems (Fuel and Lube Oil) 


660 


Working Spaces 


290 


Special Purpose Systems 


670 


Stowage Spaces 






690 


Special Purpose Systems 










300 


Electric Plant, General 


700 


Armament 


310 


Electric Power Generation 


710 


Guns and Ammunition 


320 


Power Distribution Systems 


720 


Missies and Rockets 


330 


Lighting System 


730 


Mines 


340 


Power Generation Support Systems 


740 


Depth Charges 


390 


Special Purpose Systems 


750 


Torpedoes 






760 


Small Arms and Pyrotechnics 






770 


Cargo Munitions 






780 


Aircraft Related Weapons 






790 


Special Purpose Systems 










400 


Command and Surveillance 


800 


Engineering 


410 


Command and Control Systems 


812 


Change Proposals, Scoping, Checking 


420 


Navigation Systems 


813 


Planning & Production Control 


430 


Interior Communications 


831 


Construction Drawings 


440 


Exterior Communications 


835 


Engineering Calculations 


450 


Surface Surveillance Systems (Radar) 


838 


Design/Engineering Liason 


460 


Underwater Surveillance Systems 


839 


Lofting 


470 


Countermeasures 


841 


Tests & Inspections. Criteria & Procedures 


480 


Fire Control Systems 


844 


Combat Systems Checkout Procedures 


490 


Special Purpose Systems 


850 


ILS Engineering 






897 


Project Management 



Table 7 Ships Work Breakdown Structure 



Hope and Stortz, "Warships and Cost Constraints", Naval Endneers Journal . March 1986, page 45. 
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Another particular concern is the increased dominance of combat system costs compared to overall ship costs. 
Consider the trends shown in Figure 8. The combat system cost fraction for both combatants and amphibious ships 
are steadily increasing. In the years during and following World War II, combat sy stems consisted primary of high 
densit>\ hea\'y-\veight gun s>stenis. The primary' integration issues (and thus cost and system trade-offs) were gun 
placement and provision for adequate displacement to support those guns and their amnumition. The USS Atlanta 
(CL-51) is representative of such designs (Table 8.) Its combat system suite is consistent with other World War II 
designs: low cost, low technolog>', and liighly redundant. The gun s> stems are manpower intensive, but the 
manpower is dominated by low skill, low cost gun handlers. The resulting ship has a relatively small fraction of 
acquisition cost dedicated to combat systems (less tlian 40%), and operations and support costs are dedicated to 
supporting a young, unskilled labor force. An intermediate generation of combatant ships (represented b\^ the DD- 
963 class) falls in the transition period for acquisition and design methodologies, TPP. The combat s\ stems are 
more complex and more expensive as a fraction of the total cost, which also shows an increasing trend (Figure 9.) A 
ship designed by shipbuilders (Litton-Ingles Shipbuilding), it has greater total volume to accommodate improved 
producibility and acceptance of future system upgrades. As a result of these improvements and if not for the 
government induced cost over-runs (Chapter 1. 1. 1), tlie ship acquisition cost may have been comparable to the CL- 
5 1 . Manpower is increasingly skilled in electronics, sensor management and other specialh' skills. As a result, the 
ship is not only increasing in combat systems cost, but also operations and support costs, which are dedicated to 
system maintenance and manpow er training. Tlie final generation of the combatant (DDG-5 1) is the epitome of 
current design and cost trends. The combat system is a veiy large fraction of acquisition cost. Artifrcial constraints 
imposed on displacement and length, coupled with requirements to elev ate large sensors on the superstructure, result 
in a "'beamy”, dense ship that poorly incorporates producibility features.^^ Tlius, acquisition costs are undesirabh: 
higli. Crew growth coupled with further complexities in the combat sv stem suite require the most higlily skilled 
crew s to operate and maintain. The result of these factors: DDG-5 1 has pushed tlie combat system cost and total 
acquisition cost trend to a critical level, and operations and support costs have exceeded reasonable budgetaiy^ levels. 



Phihp Sims, “Ship Impacts Studies”, Naval Engineers Journal . Mav 1993, page 87. 
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Combat System Cost Fraction 




Authorization Year 



Figure 8 Combat System Cost Trends^^ 



Ship 


Atlanta 

CL-51 


Spruance 

DD-963 


Arleigh Burke 
DDG-51 


Design Date 


1938 


1969 


1982 


Full Load (Iton) 


8440 


7800 


8300 


LBP (ft) 


530 


529 


466 


Beam (ft) 


53 


55 


59 


D10(ft) 


33.2 


42 


42 


Volume (ft^) 


700,000 


1,030,000 


971,000 


Vol to Wt (ft®/lton) 


82.9 


132.1 


117.0 


Crew 


626 


276 


318 


Combat Cost Fraction 


40 


47 


57 


Strike Weapons 


8 X 5"/38 


2 X 5’754 
Harpoon Missiles 


1 X 5754 

Tomahawk Missiles 


AAW 


40 & 20 mm Guns 


NSSM 


SM-2 


Sensors 


Small radars 
Small sonar 
Optical 


Medium radars 
Big sonars 
Towed array 


Big radar 
Big sonar 
Towed array 



Table 8 Comparison of Combatants over Time^^ 



RADM Roger B. Home, '‘Concept to Commissioning, Improving the Ship Design, Acquisition and Conslmction 
Process: Strategic Plan”, Naval Sea Systems Command, Washington, DC, June 1991. 

Philip Sims, “Ship Impacts Studies”, Naval Engineers Journal , May 1993, page 91. 
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Cost Comparisons of Surface Combatant Projects 




1970 1980 1990 2000 

Contract Award (PQ 



Figure 9 Basic Cost of Construction Trends for Surface Combatants^^ 

As a result of these trends, many cost control programs liave been implemented. First, weight-based costing 
has evolved greater fidelity. Tlie ACEIT (Automated Cost Estimating Integrated Tool) cost program is a Joint 
Service system pro\ iding a suite of costing tools designed to assist analysts in arriving at cost estimates, conducting 
”\vhat-if.^’’ studies, developing cost proposals and evaluations, conducting risk and uncertainty analysis, and 
de\ eloping CER’s. Tlie program, de\cloped and maintained b\ Tecolote Research Inc., provides many 
improv ements ov er traditional weight-based approaches including"^^: 

• User defined WBS with capability to build one or more default WBS and associated definitions, 

• Ability of users to enter their own cost equations, access a built-in Methodology Knowledge Base, search 
for analogous data, or create CER's, 

• The calculation of basic learning curv^es, shifts, rotations, rate effects, simultaneous sensitivity/”vvhat-if?" 
analyses, quantity changes, adjust for Icad/lag times with methods for time phasing, and adjustments for 
design producibility, 

• Integrated interface (AACEI) with ship design s>nthesis tools (ASSET) for real-time cost-design 
comparison. 



Colton and Company, hup.//v^^>^ \\ .coltoncompanv.com , Arlington, VA. 

Defense Acquisition Dcskbook Joint Program Office, "Defense Acquisition Dcskbook, Version 2.2.87", Wright- 
Patterson Airforce Base, Da)1on, OH, December 15, 1997. 
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• An automated cost database (ACDB) with the capabiliU' to enter, search, and retrieve cost, schedule, 
technical, and programmatic data, including contractor raw data (mapping and normalizing cost data into 
standard WBS), 

• Cost analysis statistical package (COST AT) performs statistical analyses including histograms and 
scatter plots, hnear. log-linear, and non-linear regression, and fit learning cur\ es, cost risk application 
(RISK) that performs nsk and uncertainty analysis. 

The immediate goal of tliese improvements is to provide ship design managers with robust acquisition cost estimates 
early in the design process, thus leveraging design trade-offs. However, ACEIT fits within the context of a larger 
movement in tlie DoD: the transition from acquisition costs and simple Life Cycle Cost (LCC) analysis to Total 
Ownership Costs (TOC.) 

TOC is the attempt to assess system cost beyond the boundaries of the specific platform (or ship.) In addition 
to LCC (R&D, acqmsition, operations and support and disposal costs), TOC seeks to include appropriate exiemal 
costs resulting from the development of the ship (i.e. training pipe-lines, repair facility and overhead combat 
systems, cost of a sailor, etc.) TOC is incorporated formally in the design process througli the methodolog>' of Cost 
as an Independent Variable (CAIV.)^^ Through the CAIV approach, early phases of the acquisition process (Pre- 
Milestone 1) establish an aggressive, achie\ able LCC goal based on mission requirements, reasonable deliver\ 
schedules, acceptable design baselines and expected budgetary' forecasts. At Milestone I, firm cost boundaries are 
established as well as goals for LCC reduction (the savings being reflected as TOC.) Design managers seek to 
optimize s\ stem cost, performance and schedule within tliis context. The key to achieving effecti\ e constraints and 
goals is the inclusion, early in the process, of all relevant life cycle participants. “The CX erarching IPT (OIPT) for 
each ACAT I and ACAT lA (as required) program shall establish a Cost/Performance IPT (CPIPT). The user 
community shall have representation on the CPIPT. Industry' representation, consistent with statute and at the 
appropriate time, shall also be considered. The inclusion of these participants at the earliest design stages 
provides cost estimators the ability to assess the impact on cost of critical design decisions such as producibility. 
combat s> stem design schedules, integrated logistics support (ILS) and otlier LCC issues. Thus, important impacts 
can be tested in cost models like ACEff. 

Cost and the optimization of cost goals has dominated the reforms seen m the last decade, particularly as seen 
DoD directives (CAIV in DoD 5000.) The evolution of cost models along with greater inclusion of life cycle 
participants is allowing design lev crage at the point of greatest effectiv eness, early design However, the question 
remains. . .will these enhancements effect only cost, or will the dvTiamic impacts of cost analysis result in 
performance degradation and cycle time growth? 



^ '‘DoD Directive 5000. 2-R, Mandatoiy Procedures for Major Defense Acquisition Programs and Major Automated 
Information Svstem Acquisition Programs”. Part 3 Section 3.3.3. 

Ibid. 
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1 .2 Dynamic Modeling of the Design Process 



1.2.1 Need for Modeling 

The concerning trends reflected in the DAC stud\\ increasing costs and schedule with lack of system 
performance assessment, have received substantial focus and improv ement efforts. For cost, improved cost models 
and greater inclusion of life cycle participants have highhghted ‘‘stalking horses” that may be tamed to reduce costs. 
As for performance, greater customer focus within the context of improv ed system requirement and performance 
assessment provides better means to trade performance against factors of cost and schedule. Even cycle time may 
realize significant improvements with the inclusion of IPTs, evolving acquisition strategies, and computer based 
data management and assessment. However, imlike cost and performance, nav al design process time has not 
receiv ed mush effort towards the creation of robust, strategic assessment tools Naval design managers lack the 
ability to effectively trade-off schedule with process improvements. This shortcoming is important considering the 
three primary' v ariables: cost, performance and schedule. The difficulty in managing a successful program results 
from the fact that “...the vectors of these variables are higlily interdependent and non-linear. As noted 
previously, the improv ements to costing and performance naturally impact the schedule through inclusion of new 
design participants, increasing levels of desired design tasks early in the process or introduction of previously 
unused or unavailable assessment tools. 

Traditional project modeling tools, such as PERT and CPM do provide a tool for assessing the direct impacts 
of such changes, but often fail to capture critical feedback and dependencies witliin the engineering and production 
process.^^ As a modeling technique, sv stem dv namics can effectiv ely captme such non-linearity and, thus, provide 
better understanding of the modulations of the v ariables under consideration. With respect to project management, 
system dynamics has been prov en for numerous specific applications and cases. ^ However, system dynamics has 
been primarily used for high level or verv^ specific decisions and often lacks sufficient structural detail to apply to a 
specific process (such naval design, 

A need has developed to provide program managers mth a dynamic process tool appropriately adjusted to 
reflect the realities of naval design* 



ADM WavTie Meyers (USN ret.), interview, Techmatics Inc.. Arlington. VA, November 13. 1997. 

Rodrigues and Bovvers, “System Dynamics in Project Management; a Comparativ e Analysis with Traditional 
Methods”, System Dynamics Review , Volume 12 Number 2, summer 1996, page 130. 

Ibid, page 128. 

Ibid, page 133. 
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1.2.2 What is System Dynamics? 

System dynamics is rooted, like its founder Dr. Jay W. Forrester*®, in the engineering traditions of control 
theor>' and feedback analysis. Three characteristics distinguish system dynamics from traditional management 
support tools^^; 

• Its foundation is engineering science, not statistics, 

• It relies on data to support, not control model development, and 

• It presents a dynamic, not static, environment for decision analysis. 

Specifically, system dynamics empliasizes the construction of models that capture the process of a system based on 
explicit casual relationships of variables within a closed-loop feedback structure. Data is used to cahbrate the 
model, but the verification of a model relies on common sense (agreement of the operation of the real world and the 
model structure) and formal mathematics (accumulations and flows based in differential calculus.) The resulting 
model relies on complex, non-linear relationships to dictate behavior, rather than linear, statistically based 
associations. System d> namics models still incorporate statistics during analysis as a means to test the sensitivity of 
model assumptions. But tliis analysis is intended to further validate the model rather than drive model development. 
Finally, model results are meant to be used as strategic tools to compare policy impacts, not produce explicit results 
(such as exact cost or a definitive time table.) A validated model, wliich demonstrates generally accurate behavior 
(v ariable fluctuations, chaiamic convergence or di\ ergence, and representative process structure) provides a means 
to assess policy options for '‘order of magnitude" relationships. 

System dynamics is widely accepted as an assessment tool. During the late 1950’s, Dr. Forrester, an MIT 
researcher responsible for the inv ention of random-access magnetic computer memorv , accepted a position with the 
Sloan School of Management. His interest w as the application of control thcorv' to social sv stems such as business 
and industrial processes. Since that time, his anahlic approach has blossomed into an accepted field of social policy 
anal) sis with numerous successes including: 

• Urban Dynamics, a studv^ of the policy impacts of urban housing developments, 

• Limits to Growth, a studv of earlli's ability to sustain mankind under current environmental trends, 

• The National Economic Mode L a studv of business cycles in the United States, and 

• numerous business and social process models. 

These models, as well as previously mentioned models (1. 1. 1 and 1.1.2). are particularly useful in their abilitv to 
show why a seemingly useful organizational policy fails to produce the results expected from policy managers. 

For example. Analog Dev ices Inc (ADI) of Norwood. Massachusetts, a producer of higli-end integrated 
circuits successfully applied a Quality^ Improvement Program to their production process.^^ Tlie goal of the program 
was the improvement of product quality (reduction of errors), on-time delivery and reduction of production cy cle 



Jay W. Forrester, “The Beginning of System Dynamics", banquet talk at the international meeting of the System 
Dynamics Society, Stuttgart, Gennany, July 13, 1989. 

Dr. Louis Alfeld, “The System Dynamics Modeling Methodology", Decision Dviiamics Inc, 1994, 
wvvvv.decisiondvmamics.com. 

Robert Kaplan. “Analog Devices: The Half-Life System", Harvard Business School case studv, 1990. 
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time. Tlie improvement process found great success on the production floor within a ver>^ limited time (2 years.) 
Howe\ er, when management attempted to apply their program to product development, it not only failed, it began 
ncgati\ ely impacting the production cycle. A system d\Tiamics model was generated and showed managers that 
failure to adjust the improvement program goals relative to the time scales of production versus development had 
generated the failure. Human intuition (if the improvement was effective in production it should be effective in 
development) failed to understand the d\ naniics of how the impro\ ement process disseminated through the 
organization and how' the various sectors of the organization are inter-related. System dynamics is effective at 
show ing these process factors. 

1.2.3 Modeling Approach and Structure 

Tlie procedure for developing and anal\7:ing a system dynamics model is well stated by Randers.^^ The 
procedure is applied in four stages; 

1 . Conceptualization 

2. Formulation 

3. Testing 

4. Implementation 

Witli respect to the naval design model stage 1 is discussed in Chapters 1-4 and stage 2 in Chapter 5. Stage 3 is 
presented for a few select cases in Chapter 6 and stage 4 will be considered for future application in Chapter 7. 

Specifically, stage 1 involves the consideration of the problem to be studied (as stated in Chapter 1. 1. 1 page 
13), temporal beliavior of important vanables in the problem (such as presented in Figure 1 Combatant Cycle Time 
Trends) and hypothesis of casual mechanisms within the studied process. To this end, the naval design model 
examines factors exiemal to the design process for a single surface combatant program (budgeting, performance 
changes, design resource availability within the context all naval design projects.) However, these factors are not 
explicitly modeled, rather assumed as exogenous inputs to the model. Endogenous model elements include physical 
design task flows, design organization relativ e to design resources, design decision processes and cost constraints to 
the design process. 

Stage 2 presents a specific model for a surface combatant design program (DDG-51 program.) The model 
builds on elements of previously dc\ eloped sy stem dy namics models. Tliis approach enhances mathematical 
accuracy' of the model as well as validity rclati\ c to accepted modeling practices. However, the selected model 
elements are tailored to the behav ior modes expressed in stage 1. In particular, the model reflects the impact of 
naval design task inter-relationslups based on the design spiral (Chapter 4.) 

Stage 3 demonstrates the model calibrated to the DDG-51 Program (August 1978 through September 1991. ^) 
Given replication of baseline behavior by the model, several “What if’ scenarios are proposed: 



Jorgen Randers, “Guidelines for Model Conceptualkation Elements of Svstem Dymamics Method MIT Press, 
Cambridge, MA, 1980. 

Ship Design Group, Ship Design Project Histories Volume II 1980-1989 . Nav al Sea Systems Command May 
1986, pages 2-8. 
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1 . Application of 3-D Product Models and Simulation Based Design, and 

2. Application of Integrated Product Teams and Concurrent Engineering. 

The results of these scenarios provide relative assessment of the improvement processes for consideration agamst 
accepted ‘‘mental models ’ of how those processes should effect the process. 

Finally, stage 4 discusses the future uses of the model as a tool specific to surface combatant programs (like 
the DD-2 1 program) when continuously calibrated and adjusted as process improvement results are available or 
alternative “what-if '’s are asked. As such, the model is proposed for use as a “management flight simulator’ in 
naval design programs. The model may further be incorporated into the structure of larger models addressing 
complete life-cycle (design through production through operations and support) and cross-programmatic (budget 
allocation and project phasing) issues. Finally, the model is considered for its potential role as a piece of a larger 
‘'cost-schedule-performance’' model. 
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2 Design Process External Influences 



When first analrang the problem of cycle time growth, it is necessaiy^ to understand the external influences 
that constrain and drive the design process. The externalities generally consist of strategic variables and decisions 
such as total force structure and capability (order of battle), national defense budget and budgetary allocations, threat 
capabilities and capability differentials (gap between our force and an enemy.) These externalities play a critical 
factor in cycle time growth. As such, the only true method to reverse cycle time trends is to understand and control 
the forces of the externalities. However, changes to the overall acquisition and force structure are not within the 
scope of this thesis. Rather, the goal is to establish a model representative of internal process forces, such that 
improvements proposed to the internal structure can be assessed. Therefore, vve will examine the exiemal influences 
to recognize their impact on the design process as exogenous inputs, leaving external analysis and decisions to 
alternate forums. By understanding Uie effect of external forces, the internal process can be designed to minimize 
their impact. 

The follow ing influence diagram. Figure 10. shows a number of the important reinforcing and balance loops 
which ultimately effect the design process. The loops represent those cause and effect mechanisms that act in 
concert w ith and as feedback to many of the behaviors apparent in the process of budgeting, setting requirements 
and managing schedules. Tlie loops are influenced by a combination of obser\ ed temporal variations (behavior 
modes), physical responses (decision policies and mechanisms) and structures required to close feedback processes. 
In particular, note the mechanisms influencing "Design and Acquisition Rate" (instantaneous design cycle time.) 

The rate is impacted by resource availability, acceptable risk levels and design complexit>\ The v ariables showii 
aggregate many v ariables (design and acquisition rate represents tlie average rate for all current design projects.) 

The diagram also establishes boundaries (primarily encompassing naval sliips) that could easily be expanded or 
contracted to capture additional trends. 

These dynamics represent a series of dynamics specifically noted by nav al process experts during interviews 
held August 24-28, 1997, November 12-14 and 19, 1997 and December 8-11, 1997. The interv iews included 
gov emment design managers and engineers (NAVSEA and Nav al Surface Warfare Center Cardcrock Div ision), 
commercial design support and shipbuilders (John J McMullen and Associates, Techmatics Inc, SYNTEK Inc.. 
Newport News Shipbuilding, and Bath Iron Works) and academia (MIT and Sloan School of Management.) A 
complete listing of personnel interviewed can be found in Chapter 8.2. 

The dv namics are examined indiv idually to clarify their inclusion in the totality of external process 
influences. 
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Covered Naval Conlmitments 




'Pressure for Required Performance Addition (+OMOE)> <Funds Remaining for R«feD Sc SCN> 




2.1 Reciprocity and Proliferation... the Need for Naval Capabilities Evolution 

In his 1996 thesis on the naval ship production process \ Tim McCue introduced the concept of the "Arms 
Race Dynamic.” This d\Tiamic is showTi in Figure 1 1. There are two dynamic loops at work in this process: the 
Proliferation Dynamic and the Reciprocity Dynamic. The Proliferation Etymamic is well understood by miliian' 
strategists and is a source of debate with respect to international control of weapons and capabilities (particularly 
weapons of mass destruction and “smart weapons”. The Proliferation Dynamic is a “snowballing dynamic” and 
may be characterized as follows: 

1. As new weapons and doctrines are introduced into serv ice by US forces, these capabilities will diffuse 
(or proliferate) over time such that tlneat forces possess reciprocal capabilities (either equiv alent or 
negating) 

2. As proliferation carries on, US intelligence metliods will characterize the threat based on actual and 
consequentially, perceived capability^ of the threat force 

3. The perceived threat will be weighed against US capabihtics resulting in a US adv antage (or deficiency) 

4. As proliferation continues, the US adv antage will decline and pressures to enliance US capabilities will 
begin to increase 

5. As pressures to enhance capabilities increase, the US forces will improve 

6 Force improvements will be noted by the threat force that will in turn seek to gain the same enlianced 
capability^ or a negating capability. . .and so on. 

The Proliferation Dvnamic has many other details not noted here (such as cost of new capabilities, tecluiological 
complexity and political landscape) which have significant impact on the rate of proliferation. However, time has 
shown tliat proliferation rate may be moderated but as long as inequalities exist diffusion will occur. 



^ Timothy P McCue, “The EHnamics of Naval Shipbuilding-a Systems Approach”, Department of (3cean 
Engineering Thesis, Massachusetts Institute of Technology, June 1997. 

William S. Cohen. Report of the (Quadrennial Defense Re\iew, United State Department of Defense, May 1997. 
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Figure 11 Arms Race Dynamic 

In order to balance the threat of Proliferation, US forces must follow with Reciprocih Tlie ReciproeiK 
Dynamic is characterized as follows; 

1 . US forces start at a gi\ cn force level (US Naval Order of Battle) 

2. The US force has an inherent capability advantage (or deficit) when compared to potential threat levels 

3. Pressures to increase US capability (typically political) increase as the US advantage is decreased 

4. Tlie source of new’ miUtarv’ adv antages may originate from new capabilities (new ships, weapons, etc.) or 
changes to enliancc doctrine to emplov’ current forces 

5. Capabilities increase the US advantage until pressure to improve is nullified. 

As with Proliferation, Reciprocity can be further described by additional v ariables such as current political climate, 
defense costs and the state of the US economy, or perceiv ed level of international stability’. Howev er, as long as the 
US continues to choose a role as a leader in world affairs, militarv’ strength (advantage) will likely be the doctnne of 
choice. 

Two detailed expansions of tlic Arms Race Dv namic are also demonstrated. First, the new construction 
dynamic demonstrates tliat one metliod of increasing capability' is to develop nev\’ weapon and ship sv stems The 
construction of new designs (increased with increasing design rates, measured as nev\' designs completed over time) 
results in the increased order of battle. ..completing the reciprocity’ balancing force. A second dvnamic expansion is 
tlie impact of technology from proliferation. As proliferation of adv anced defense technologies occurs, the 
complexity’ of new designs required to counter those teclinologies increase. As complexity’ is increased the design 
rate slov\ s (more time is required to gain equivalent leaps in perfonnance advantage), new constructions slows and 
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the order of battle decreases... ultimately the abilit}^ to maintam capabilit\' advantage will be lost to the balancing 
force of technological complexity. 

The *'Arms Race Dy namic'’ lies at the heart of the Na\ al Design Process as the primaiy' influence effecting 
the need for new designs, the need to support operating forces, the mcreasing complexity of newer designs and the 
acceptable levels of risk relative to cost, performance and cycle time. Consider Figure 12. Correlated against the 
trends shown in Figure 1 and Table 8, US warships have been dedicating larger fractions of procurement costs to 
combat s> stems in response to ever growing threats, while the combat sy stems themseh es are achieving 
e\TX)nentially decaying improvements in capabihty. and the net development cycle is slowing to accommodate 
assessment of tlie threat and de\ elopment of systems capable of countering those threats. As long as new threats are 
generated and the US chooses to counter those threats, the cy cle will continue to generate the need for a non-zero 
design and acquisition rate. 




Figure 12 Naval Surface Combatant AAW Reaction Time Trends^^ 



2.2 “Order of Battle” Dynamics... Maintaining Force Levels 



Tliis second dynamic both drives the need for new' designs and counters the ability to produce new designs. 
Shown in Figure 13, the "Order of Battle” dy namic demonstrates the mechanisms by wiiich e\ en a static threat 
ultimately requires creation of new designs. First, consider the “Graying” Fleet Dy namic. For a static capability' 
lev el, time eventually degrades the capability. For Example: 



Prof Charles Cahano, Total Ship Sv stems Engineering, http://web.npgs. navT.niil 

39 



1 The current US aircraft carrier capability is known (Figure 14). 

2. The desire for the US to engage specific commitments (Persian Gulf, Adriatic or South Chma Sea) 
results in carriers being assigned to the regions. 

3. As commitments increase for the fixed number of carriers, the average aging process for those committed 
carriers increases. 

4. As carriers age, the useful life is expended imtil decommissioning. This increases the average age of the 
total fleet but at the cost of reducing tlie overall order of battle. 

5. Finally, as the age of ships increases and fewer are available due to decommissioning or increased 
maintenance time for older vessels, the order of battle decreases. . . 

These balancing forces (meeting commitments ultimately means not meeting commitments) are reversed by the 
counter-balance of the reciprocity dynamic. This is one of the factors currently driving the CVX program to replace 
aging carriers (Figure 14.) 

An additional chnamic proceeds from the "Graving" Fleet dvnamic... Fleet Demand Dvnamic. By this 
dynamic: 

1 . Increased fleet age (as a result of time and increasing commitments) generates pressure from operating 
forces to devote funds to maintenance and support of operating ships 

2. The pressure increases as the total force lc\ el increases and limited funds are allocated across a larger 
inventory of operating vessels 

3. The pressure translates as an increased demand on engineering resources (commercial and nav al) to be 
dedicated to fleet support vice development activ ities, 

4. The pressure forces increased operation and support (O&S) expenditures within the fixed constraint of 
total available defense budget, 

5 The increase of fleet support resources and O&S expenditures reduces available funding for development 
projects, 

6. Tlie increase of fleet support resources and O&S expenditures improves the Order of Battle vvliich 
increases naval commitments covered, 

7. Ultimately increasing the average age of v essels. . . 

The result is reinforcing behavior. . .aging ships demand resources to maintain force levels which demand more 
resources and so on. This behavior fueled much of the deficit spending required to supported the defense build-up 
of the 1980's. 

A third behav ior has been especially apparent in the last few years, a trend to pay for newer capabilities with 
the decommissioning of older vessels . . . "Pay with Past" dynamic. Consider the follow ing trends: 

1 For a giv en force lev el (order of battle) decommissionings mav^ be considered to reduce O&S 
e.xpenditures, 

2. As more slups are decommissioned O&S expenditures decrease which increases funds a\ ailable for 
procurement (R&D and SCN), 
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3. Allocations of procurement funds to industr\' and government resources result in a pool of Engmeenng 
and Acquisition Resources, 

4. As this pool increases the design rate (new designs produced over time) increases and new designs and 
acquisitions result, 

5. Ultimately increasing the order of battle in the fonii of new ships and capabilities. 

Tins behavior is balancing. . . decreasing order of battle w ith decommissioning w ill increase order of battle w ith new 
construction. During the down-sizing of the 1990’s, many new construction programs and upgrades to operating 
units w ere funded with tlie decommissioning of older vessels. However, tlie majority of the recovered funds were 
lost to a shrinking defense budget and increases in O&S funds required for support of US commitments (Somalia, 
Haiti, Bosnia, Persian Gulf, etc.) 

A final beha\ior of note is the Industrial Demand Dynamic. Proposed by Dr Harv ey Sepulski^*^ 
(Massachusetts Institute of Technolog>), this dvTiamic has received significant focus from the defense industrv^ in 
recent years: 

1. If allocations for contracted resources decreases (due to decreasing defense budget funds), there is 
increased pressure from industrv' (on Congress and on government acquisition authorities) to privatize 
government operations 

2. As pressure increases, greater portions of funds are given to industrv', 

3. The increased allocation to industrv' decreases pressure for privatization. . . 

The result is a balancing force w ithin the defense industrv’ with respect to available defense funds. Note that 
increasing privatization must be coupled with decreased in-house resources for a fixed budget. 

Tlie dynamics of these Order of Battle factors impacts the design rate tlirough fund allocations (giving and 
taking from development programs) and as factors requiring the introduction of new forces to replace older ships. 
Many of these dynamics are currently being examined by industrv^ as potential areas for privatization of fleet support 
expenditures. ^ 



Presentation to Ocean Systems Special Project course at Massachusetts Institute of Teclmologv, Spnng 1997. 
' ^ Prof Jim Hines, Applications of System Dvmamics course project supporting the Boeing Corporatioa Sloan 
School of Management, Cambridge, MA^ Spring 1998. 
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Figure 14 Timeline for US Aircraft Carrier Development and Decommissioning 



2.3 Design & Acquisition Rate Influences 

The cycles of the Arms Race and Order of Battle are shown to demonstrate tlieir influence over the topic of 
primaiy concern: Design Rate. In particular, it is important is understand how these d>namics control design rate 
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(and thus, design cycle time) tlirough the functional input of performance and cost. Figure 15 show s an expanded 
view of these inputs. It has already' been shown implicitly that design rate is impacted by changes taking place in 
cost and performance (Chapters 1.1.2 and 1 . 1 .3) as well as by the dynamics of performance requirements (Chapter 
2.1) and cost constraints (Chapter 2.2.) Design rate is also explicitly impacted by cost and performance constraints. 
Consider the case of the DDG-51 program. During the preliminary' and contract design process, design managers 
applied an approach of a ‘‘closed loop feedback control process of establishing budgets, re\ iewing the design for 
conformance to the budgets, and making decisions to change the design (within performance constraints) where 
design features exceeded the established budget.”^^ Figure 16 demonstrates this form of “dynamic cost control*’ 
with an exponential increase in cost from an initial baseline througli the end of the Feasibility' Design Phase 
followed by a very rapid oscillation beginrung in May 1983 to stabilize the cost ($700M follow-ship acquisition cost 
in FY83$.) Coincidentally, May 1983 represented the official start of the Contract Design Pliase. . .a period during 
w hich cost becomes veiy’ apparent and engineering manpower rapidly' ramps-upyvard to facilitate increasing design 
tasks^^. The result of this process yy as a lengthening of the design schedule by sey eral months to accommodate the 
additional analy sis and revieyv.^^ 




Figure 15 Design Rate Dynamic Inputs 



Hope and Stortz, "Warships and Cost Constraints*’, Nay al Engineers Journal, March 1986. page 43. 

Ship Design Group, Ship Desigui Project Histories Volume II 1980-1989 , Naval Sea S> stems Command, May’ 
1986, pages 2-8. 

Hope and Stortz. "Warships and Cost Constraints". Naval Engineers Journal, March 1986, page 46. 
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Figure 16 DDG-51 Contract Design Procurement Cost Estimate Trend" 
Tliese inputs and cycle time dynamics are explained by the following influences: 
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Increases in design complexity (performance required) lengthen tlie design process (slow the design rate) 
Decreases in design funds and engineering resources lengthen the design process as acquisition 
authonties become risk adv erse (hesitant to commit funds) and basic resources become diluted among 
design projects 

3. As perceived threats from proliferation and decreasing US advantage become apparent, pressures to 
increase design rate (shorten cvxle time) come from reduced schedules and willingness to accept greater 
design-performance risk 

4 Finally, as the volume of designs in progress increases, the rate naturally adjusts (balancing) as schedules 
for immature designs are relaxed to focus resources on designs in the later stages of completion. 

These influences represent the input variables that must be considered for inclusion in a design process model. 
Howev er, these vanables are exiemal to a specific design project. Althougli a design manager must consider issues 
such as increasing performance requirements or reduced funding from the defense budget, he has little control over 
budget allocations to other programs or tlie cancellation of a teclmolog>' pipeline bv' a sister service in the DoD. As 
such, these variables are included as exogenous inputs to the model. The model provides a means to change the 
assumptions of the inputs, thus allow ing the gaming of potential scenarios driven by those influences. 



Vernon E. Stortz, ‘‘DDG-51 Design-Cost Trend Log”, unpublished, Naval Surface Warfare Center Carderock 
Division, Bethesda, MD, August 1984. 
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Design Process Dynamics 



3.1 Systems Engineering and Nava! Ship Design 

The naval ship design process is the process of establishing a mililar\' need, defining this need in terms of 
militar\' requirements and constraints, performing a set of design tasks to develop a solution, validating the solution 
versus the requirements, and translating the solution into a form usable for production and ship support. Figure 17 
demonstrates this concept and it’s iterative elements. These steps are repealed at each stage of the design process, 
from concept to production design, with the detail of the tasks increasing concurrently with the maturity of the 
design. 



Design Elaboration & 

Design Iteration Error Correction 




Iterathe Trade-Offs 



Figure 17 Systems Engineering Process^® 

The dominant accumulations and flow s in this generic process are as follow s: 

1. Input requirements generation (such as tlireat analysis and Mission Need Statement (MNS) generation) 
with tasks for analysis of mission needs 

2. Functional analysis tasks (such as Industrial Base Assessment and Analysis of Alternatives) that establish 
reasonable system options 

3. Synthesis tasks (such as hullfonn design or combat s> stems integration) that define and optimize the 
system 

4. Evaluation and decision (such as ship vulnerability modeling or milestone approvals) witli tasks to 
examine and approve or disapprove completed design tasks, and 

5. Description of System Elements (such as Contract Specifications or Construction Draw ings) to translate 
system requirements into component and production specifications 

Several important feedback flows are apparent in the process. Iterations may result from physical design 
balance, design errors, risk mitigation, scope change, and modification of input requirements. Physical convergence 
is centered on design svntliesis. 

Synthesis in naval ship design is modeled in the design spiral. The dynamics of spiral concurrence and 
information transfer are a unique property of naval sliip design. A more detailed discussion is presented in Cliapter 
4 



Kockler, Withers, Poodiack and Giemian, Systems Engineering Management Guide , Defense Systems 
Management College, Januarv' 1990, page 1-3 and 5-2. 
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An important source of feedback is error disco\ er>^ and correction. Errors themselves may be generated at 
any stage of the process. Early in the process, errors occur when objectives and requirements are erroneously or 
imperfectly specified. The mechanisms described m Chapter 1. 1.2 are designed to mitigate the probabilit\' of errors 
in these stages. During later stages, errors may be caused by communication disruptions (design hand-offs), 
misinterpretation of specifications, inaccuracies or singularities in design algorithms (computational inaccuracies, 
design modeling assumptions or discontinuities in design variables), and human factors.^^ 

Error detection and management topically occurs during specific Quality Assurance (QA) stages. QA is 
defined as '‘a set of activities performed in conjunction with a (project) to guarantee the product meets the specified 
standards... these activities reduce doubts and risks about the performance of the product in the target 
environment.”^^ As errors are detected, the deficient tasks are relumed to an appropriate stage for correction. As 
demonstrated in Figure 17, error correction t}pically returns to s>Tithesis. For this reason, it is possible that the 
correction stage may not be the source of the error, thus providing the potential for future error generation. Note 
that this is a reason for the emergence of Total Quality Leadership (TQL) within the Navy as a method to anal\7;e 
errors and their causes. 

A final source of iteration is the modification of requirements and functional analysis products resulting from 
evaluated designs. These modifications can include design changes (failure of the current design to meet 
requirements) or changing requirements themselves (necessitated by cost or performance trade-offs.) Additionally, 
as the project proceeds through time, the requirements themselves change in response to changing external needs 
The result is scope growth. Such growth has a negative dviiamic impact: reinforcing work to be done and often 
dominating the balancing effects of iteration Consider a study of scope change impacts conducted by the 
Construction Industry^ Institute.^^ The stud\' e.xamined tlie change in productivity resulting from increasing fractions 
of change. The study compiled data for 104 projects from 35 different companies. The results showed that 
engineering productivity (measured as a ratio of earned work-hours to expended w ork-hours) decreased linearly at a 
rate of 5% productivity for 10% increase in design changes. Tlie effect translated into similar productivity decreases 
for construction. 

3.2 Acquisition Process... Points of View 

To facilitate the management of the above systems engineering approach, the Department of Defense has 
formalized the stages and processes. Tlie foniial process is referred to as the acquisition process. Figure 1 8 show s 
the major phases and milestones of the acquisition process. The acquisition process includes many steps that extend 
both before and following s\ stems engineering. For instance, pre-Milestone 0 includes not only requirement 
definition (Determination of Mission Need) but also the examination of available technologies (Science and 
Technolog>) that would be required to support Functional Analysis (Concept Exploration.) The examination of 



Abdel-Hamid & Madnick, Software Project Dynamics: an Integrated Approach , Prentice Hall, New Jersey, page 
95-96 

Ibid., page 101. 

Construction Industiy^ Institute, “C}uantitati\ e Effects of Project Change ', ClI Source Document, March 1990. 
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technologies may itself be a systems engineering exercise as managed research solutions must be constantly 
assessed for the range of applications to which those technologies are being developed. The acquisition process also 
extends beyond production level engineering at Phase II (Engineering & Manufacturing Development.) 

Specifically, the acquisition process manages tlie complete production (Phase III) and support (Operational Support 
and Demilitarization & Disposal) for tlie fielded s> stem. As such, tlie acquisition process encompasses not only 
system dev elopment, but the entire life cycle of the s\ stem. 




Figure 18 Acquisition Milestones and Phases^^ 

Perhaps the largest difficulty in understanding the na\ al ship design process (or any defense design process) 
is the large field of views that process observ ers may take. Consider Figure 19 below This diagram shows the 
range of management considerations (shown as timelines) contained within the DD-21 acquisition process. Within 
this program, participants may take widely differing process views based on tlieir own requirements to focus or 
optimize process efforts relativ e to a particular trade-off. For instance, the primarv' engineering focus is the 
sequence of design reviews (ASR through FCA) necessary to define conceptual baselines, svstem definition and 
design producibilitv'. The engineering view seeks to provide the best physical system (pcrfomiance) as a response to 
the giv cn requirements. Altemativ ely, budgetarv' and fiscal managers are focused on milestone relationships, since 
the satisfaction of specific milestones translate directly into funding increases required to support continuing levels 
of design effort. Additionally, budgetarv’ managers optimize the use of funds against budgetarv’ and fiscal nsk. 
Industn^ and acquisition managers must concentrate on the vanous contracting phases (in addition to the other 
process phases) in order to maximize allocation of intermediate program funds (such as support contracts) while 
remaining poised to compete for the final contract award. Additionally, industry managers seek to optimize 
producibilitv' relative to their own production processes. Through optimization of cost and schedule, industrv seeks 
to gain a competitive advantage for contract award. 

Each of these points of view are seeking to dev elop a systems level optimization of the final design. 

However, the optimization is relative to the area of concern to the particular component managers. This is not to say 
that component managers ignore total system optimization. They arc quite aware of the potential impacts resulting 
from changes to a particular sv stem element. Tliey are especially sensitive to the impacts of changing inputs 



Defense Acquisition Dcskbook Joint Program Office, "'Defense Acquisition Deskbook, Version 2.2.87”, Wriglit- 
Patterson Airforce Base, Da>1on. OH, December 15, 1997. 
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resulting from s> stem interdependencies. Ev er changing requirements of the military and resulting changes in 
optimization priorities dictate that no one element dominates through the entire design process. As such, component 
managers must constantly strive to champion their s> stem element to achieve necessaiy^ consideration in the final 
design. The dy namic impacts of these changes have already^ been demonstrated (see discussions of Table 2 and 
Figure 16). These competing relationships and task interdependencies are examined in detail in Chapter 4. The 
immediate results of compartmentalized and competing demands are obvious: each component manager pushes 
fonvard with necessary' tasking despite changing priorities and no one component \iew delivers total system 
optimization. 

In this environment of competing sy stem interests, it is the task of the program manager to assess the needs of 
the de\ eloping system, determine the range of available resources, and assign priorities to optimization goals. 

Within this context, the program manager works to the following principles and objectives’.^^ 

• Ensure effective design and price competition. 

• Improve system readiness and sustainabihty' 

• Increase program stability through effectiv e long-range planning, use of ev olutionary' alternatives, 
realistic budgeting and funding of programs for the total life cy cle, and planning to achiev e economical 
production rates 

• Delegate authonty’ to the lowest lev els of the serv ice that can prov ide a comprehensiv e rev iew of the 
program. 

• Achieve a cost-effective balance betvv een acquisition costs, ownership costs, and sy stem effectiveness in 
terms of the missions to be performed 

Giv en this range of responsibilities and management decisions, the program managers tasking in the design process 
naturally extends to all facets of the project. Tins fact is explored more fully in Chapter 4.4. 



Kockler, Withers, Poodiack and Gierman, Systems Engineering Management Guide , Defense Systems 
Management College, January' 1990, page 2-1. 
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3.3 Operational Process View 



3.3.1 Design Phases 

Increasingly, naval ship design is becoming a subset of total ship s> stems engineering (TSSE). Ship concept 
exploration and combat s\stem development must begin well in acK ance of the actual ship design process. As such, 
the superset of system design spaces will encompass many layers of system optimization and process view s. Tlie 
global exdeniahties described m chapter 2 represent a strategic view of the design process. The sy stem design and 
acquisition processes described m sections 3. 1 and 3.2 represent macro \ie\vs of the design process. The remaining 
views are operational views. The operational views provide the exacting structure that is necessaiy^ to capture the 
dvTiamics of design process change relative to process improvements. Specifically, the operational views are 
represented by the notions of Design Phases and the Design Spiral. The design spiral is examined in detail in 
chapter 4. This section examines the four phases of naval ship design: Concept Design, Preliminary' Design, 
Contract Design and Detail Design. 

Concept Design is the phase during w hich the solution space is examined to identify potential cost-effective 
solutions to the stated requirements. In the acquisition process, this stage is represented by all activities prior to 
Milestone I. The requirements are presented by the ongoing Requirements Definition subphase during which 
warfighters recognize an operational need and translate that need into requirements for engineering and acquisition. 
The overall ship sv stem is emphasized w ith specification of components limited to a few significant sv stem driv ers, 
such as w eapons or propulsion plants. The products of the Concept Design are a set of defined requirements and a 
design space of achievable solutions to requirements. 

Note that the iterative properties of the macro view' of systems engineering are present both externally and 
internally. Externally, the concept design phase represents the first stages (requirements and functional analysis) of 
systems engineering. Internally, concept design contains explicit elements of all sy stem engineering 
steps. . . requirements, sy nthesis, approval and description of sy stem elements for the next phase. These intenial and 
external characteristics are common to all design phases. 

Preliminary Design is that phase during which one or a few desired concepts are refined by analysis and 
integration of specified components to confimi acceptable system capabilities. In tlie acquisition process, 
preliminarv' design is represented by Phase II (or more often Phase II A.) Tlie purpose of preliminaiy' design is to 
focus on ov erall system effectiveness and assurance that specified sy stems can be technicalh and economically 
supported b> the ship design. In particular, engineers and managers concentrate on liigh risk elements of the design. 
Such higli risk elements may include: industrial base support, combat systems integration, hullfomi performance 
characteristics. life cycle cost, or optimization of marine svstems efficiency. As a result of in depth analysis of 
specific systems, the products of preliminarv' design contain increasing degrees of component specification, but still 
focus primarily on sy stem level definitions. 

Contract Design is the specification of design attributes necessarv’ to reduce risk for the Na\y during the 
av\ ard and constmetion of the selected design. Tlic contract design process is still functional!) oriented. However. 
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increasing numbers of components are specified in detail. Specifically, design attnbutes are specified by contract 
specifications to constrain design performance and reduce risk. These constraints may in turn constrain costs, 
possibly to the detriment of the design process. Like preliminary’ design, contract design is part of phase II of the 
acquisition process (or phase IIB). 

It is important to note that ilie traditional design responsibility up to and including contract design has resided 
with the Na\y. As discussed in Chapter 1.1.1, NAVSEA would conduct the bulk of engineering analysis with 
contractors providing support services, but providing little influence over the direction of the design. However, this 
trend is changing. Recall the transition points show n in Figure 5. Under the old (DDG-51 and prior) approaches to 
surface combatant design, the end of contract design represented tlie transition point of the design from the 
govermnent to the shipbuilder. Under this approach, the shipbuilder received very specific contract and mihtaiy' 
specifications directing tlie materials, components, and even production methods for the design. As shown 
pre\1ously, the result of tliis inflexibility’ was delays due to late GFI/GFE/GFM, schedule and cost growth in excess 
of marginal scope changes, and increasing ship production costs. To counter these effects, current programs (DD- 
2 1) are pursuing earlier transition of design responsibility’. Bv' specify ing performance requirements, shipbuilders 
are free to pursue design alternatives optimized to their production capabilities. Although the contractors will 
assume early design responsibility , there must still be a detailed contract specification prior to shipbuilding contract 
award Tliis contract specification is necessary’ to define the product for which ship construction funds (SCN) are 
allocated as well as commit the shipbuilder to legally binding design perfonnance (i.e. a performance specification 
will not hold the weiglit of a contract specification in a court of law.) 

Detail Design is the phase during which s> stem descriptions are translated into the instructions required to 
support constniction, operation and support of a finished ship. Williin Detailed Design are four sub-phases required 
to support contractual and production requirements During Functional Design, the shipbuilder specifies ship 
system components and verifies that the selected systems will satisfy performance requirements. Functional Design 
provides the linkage betw een desired s> stem configuration and specified performance predicted b}’ contract design 
and realized s> stem performance available from a producible design. Functional Design is sometimes associated 
with contract design by the notion of Contract Definitization. Tliis is potentially significant when multiple lead 
ship contractors are bidding for a project. During such instances, functional design represents a further 
demonstration of design quality’ and cost for differentiation of contract bids. Howev er, experience has shown that 
lead ship design aw ards typically proceed in advance of contract design end As such, functional design becomes 
the initiation of detailed design concurrent with completion of contract design. Transitional Design takes the ship 
system description and incorporates it into a process-based description Long lead items (propulsion engines, 
propellers, combat system components, etc) and material requirements lists (MRL's) are incorporated into the 
shipbuilder logistics sv^stem. Zk)nal Design develops components into drawings consistent with the work 
breakdown structure required for ship construction. After this subphase, tlie Navy will own and, witliin contractual 
limits, distribute the design to all ship builders who hav e successfully bid for a constniction contract. For tliis 
reason, these first three sub-phases of detailed design (Functional, Transitional and Zonal Design) are often referred 
to as Lead Ship Design. For a lead ship design effort, tlie products are intended to support all ship builders and 
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component vendors participating in the ship construction program. However, the actual process will often result in 
detailed design attributes that support the construction of the ship in the Lead Ship Yard As such, participating 
yards will necessarily modify the Lead Ship Design to be compatible with their production processes. The result is 
the ver\' notable difference between ships of a common class built in competing ship yards. The final stage of 
design. Production Design or Manufacturing Engineering, begins as soon as engineering and production 
resources, as well as zonal design products, permit initiation. Production Design extracts the final drawings (lofting) 
and manufacturing instructions required to produce the ship. This phase also provides the interface with the 
construction site to resolve design conflicts encountered during construction. 

3.3.2 Scope Change Implementation and Detailed Design 

Detailed Design is influenced by dynamics encountered due to ‘'Internal Change” (producibility 
accommodations, error and interference) and “External Change” (engineering change proposals and GFIATI 
changes).^^ Internal Change represents those factors over which the design organization has some degree of control. 
Internal changes include Engineering Assistance Requests (EARs) or producibility enhancements. The dynarmcs of 
internal changes require assessment of the improvement versus detrimental impacts. For instance, error rates cai be 
reduced with increased QA. However, increased QA naturally delays the schedule and commits valuable resources 
away from tasking. Tims, a trade-off must be determined internal to the project. External Changes are those factors 
over which the organization has little control. External changes are either Nav>^ Engineering Change Proposals 
(ECPs) or vendor changes. For instance, as requirements change, the design must change (despite the negath e 
system impacts of change) otherwise the design fails to meet the perceived need. 

All clianges are anal>'zed for schedule, material and production impact. The level of analysis varies 
depending on the complexity of the change. A simple interference identified by an EAR will be anah^ed by the 
production design representative on the waterfront and processed in accordance w ith standard procedures. A 
complex ECP is anal\7:ed by system and functional engineering, design, material engineering and planning 
specialists. If the proposed change is considered necessaiy , an action plan is developed which integrates the change 
into design and construction process. 

Design changes originating during the construction process are pro\ ided to manufacturing as interim products 
known as “Revision Notices” (RNs). Tlirough a “lock-step” process, fabrication and installation drawings extracted 
from the CAD models are continually maintained to reflect the current design baseline via RNs. It is essential that 
configuration control of the models and drawings be maintained while new design changes are introduced. Re\ised 
drawings are reproduced at regular intervals to support the next follow on hull that take into account the multiple 
design changes created during the construction of the pre\' ious hull. During these maintenance cycles, all 
outstanding change paper is accounted for and a “clean drawing” is produced. Similar to the lock-step process, parts 
lists are continually updated as changes are identified. External Change and Internal Change are specific 
representations of scope growth of a project. 

C. R. Lloyd, “Design Process for the AEGIS Destroyer Program”, Presentation, Bath Iron Works D87 Class 
Design Office, November 18, 1997, page 6. 
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4 Design Spiral and Task Dynamics 



4.1 ‘The Design Spiral” 

The design of a ship is not the act of designing specific equipment. . .rather; it is the integration of systems and 
equipment to optimize cost and effectiveness.^^ Such activity is inherently multi-disciplinary (“no single person can 
be expert in all these areas"^^) and highly iterative. However, this is not to say that the process is without 
recognizable structure and organization. To the contrary, the naval ship design process must follow very specific 
steps and satisfy fundamental physical laws in order to achieve a balanced design. These balanced properties range 
from the most basic (hydrostatic balance, resistance-to-powering balance, stnictm-al stress-to-integrify’ balance, etc) 
to those demanded for increased effectiveness and decreased cost (passive-vs. active-defense trade-offs and design 
optimization vs. producible design.) 

Tlie most widely accepted methodolog>’ used to balance design requirements to ship components is the design 
spiral. The design spiral describes the process that compartmentalizes the design disciplines and regiments the 
engineering steps necessary for a balanced design. Figure 20, shows a fypical example of such a spiral. (Note that 
the concept of the design spiral is attributed to Professor J.H, Evans of MIT and was first introduced in the Naval 
Engineers Journal November 1959.) 

Fundamentally, the spiral is a shij>system algorithm that combines physical relationships with trade-off 
options. The spiral is characterized by a sequence of specific tasks that incorporate initial design requirements, 
synthesize these requirements into a set of design characteristics, assess the design characteristics against the 
requirements and against one another, and iterate as necessary to achieve convergence of the \ alues. The design 
spiral relies on three important features to enable analysis and convergence. First, tlie design space from which all 
potential design characteristics may be chosen is not infimte. Rather, the design translate into a specific design 
space (known as design lanes.) Tliese design lanes enable engineers to assume a set of initial ship characteristics 
and, thus, proceed with the design analysis. Secondly, the spiral generates specific design characteristics and 
modifies the values as nccessarv^ to meet requirements. As such, the design assumptions at the beginning of a spiral 
differs somew hat from tliose at the end of an iteration. The spiral process incorporates the new design values into 
each successive iteration until the values converge to a balanced design. Design balance indicates the defined ship 
characteristics are physically stable while satisfying design requirements. It is important to note that a balanced 
design may not necessarily represent the optimal design.^^ Finally, as iterations proceed and convergence is 
achieved, the process of synthesis and analysis seeks greater and greater levels of detail. For instance, imtial 
structural analysis incorporates simple beam theory; ship section modulus and accepted design practices. Later 

Gale and Scott, "Early Stage Ship Design Seminar'; The Sociefy^ of Naval Architects and Marine Engineers, 
October 1995. 

Tibbitts and Keane. "Making Design Everybody's Job'’, Naval Engineers Journal. May 1995, page286. 

Allan Andrew, “Multi-Attribute Decision Making Analysis with Evolutionary^ Programming Applied to Large 
Scale Veliicle 11”, Thesis for Ocean Engineering, Massachusetts Institute of Technology, Cambridge. MA, Mav 
1998. 
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iterations incorporate greater design detail such as finite element analysis for both static and d>mamic loads. Finally, 
the design incorporates structural arrangement details necessary^ for construction. Each increase in detail requires 
comparison of design characteristics for convergence. The result is a com ergent. producible design and greater 
confidence with respect to design requirement risk. 




Figure 20 Generic Ship Design Spiral 

There is no one spiral that is correct for all ship designs. A proposed spiral must incorporate design and 
analysis elements necessaiy^ to satisfy requirements. In particular, the spiral task elements may vaiy^ by mission 
requirements, le\ el of risk mitigation required or level of sub-system and total s> stem maturity’. For those general 
design disciplines that are chosen for a given spiral, sub-spirals may be necessary within a design node in order to 
generate and analy7:e specific design characteristics. For example, it is necessary^ to balance auxiliaiv’ system 
capacity' to electrical power generation to payload support requirements w ithin the marine engineering discipline. 
The consequence of layers of design and analysis is a set of nested iterations of design w ithin the o\’erall design 
structure. Figure 2 1 shows an example of this concept. Additionally, the \ iew of the spiral may change to 
acconmiodate varying process interpretations: viewed as eitlier mo\ ing from the outer rings inward or from the 
center outward. If outer to inward tlie \ iew is one of considering the initial de\'elopment of numerous conceptual 
designs witli each narrowing ring focusing the effort to few er and fewer design options and culminating in a single 
final design. Alternately, the view of increasing arc lengths from center to outward represents the increasing detail 
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required of each iteration to validate the final design . Whatever the view or structure, the spiral provides a common 
baseline to begin discussion of design process and disciplines necessary to develop and evaluate the design. 




Figure 21 Nested Design Iterations 

These views of the design process are consistent with the basic structure for project models utilized in svstem 
dynamics. Namely, the iterative nature reflects a necessity to take a set of initial (or baseline) tasks to be done, 
perform those tasks to a level of productivity, and rework the tasks due to vaiying levels of design quality. Figure 
22 shows an example of the sv stem dynamics model structure. For naval ship design, the sv stem dynamics variable 
‘initial work to be done" is equivalent to the number of design nodes within the design spiral. Productivity is the 
rate of design accomplishment consistent with the number of designers assigned to and the complexity of the task. 
Quality may be interpreted as the rate of design convergence (i.e. the quantity of tasks requiring re -iteration.) 
Undiscovered rew ork and rework discovery' represent tlie analysis steps of the design spiral Know n rework and 
rework accomplishment represent subsequent iterations of the spiral. 

For typical project management models, tliis sy stem dynamics structure is the basic “engine" for process 
flow. Tlie base structure is then adjusted sy stemically to accoimt for the impacts of v arious project management 
policies. For example, manpower allocation, budget, scope changes, project schedule, ov ertime and others may 
introduce feedback effects on productivity, quality, and work to do. These structures are explored more fully in 
Chapter 5. Process Model Sectors. 

As a basic system dy namics structure (or molecule^"), it is possible to begin using this structure to analyze the 
naval ship design process. However, the design spiral, as presented above, does not completely capture the design 
process. It is necessary' to understand that the spiral interpretation does not fully reflect the method of design used 
by engineers. 



David Brown, “Naval Architecture", Naval Engineers Journal . January' 1993, pages 43-44. 

Jim Hines, “Molecules", a presentation to MIT-Sloan course Application of System Dynamics, Cambridge, MA 
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Figure 22 Generic System Dynamics Project Structure^^ 

Consider a sampling of tasks for a typical ship design (Table 9 and Figure 23.) Tlie listed tasks 
(arrangements, structural analysis, propulsion...) represent specific points on the design spiral. Note that the 
number of issues for each task element are not the same. Each iteration of the design spiral is not equivalent with 
respect to the tasks to be done. Additionally, the time duration of each issue that is performed during a design 
iteration is non-linear (note the numerous slop>e changes in both iteration duration and periods between tasks.) Tliis 
indicates the order of tasks within the spiral is changing. The design spiral is not linear. 



Task 


Preliminary Design 


Contract Design 


General Arrangements 


1250 Hours 


3250 Hours 


- General Arrangements Drawings 


3 Issues 


4 Issues 


- ArcaA^olumc Report 


3 Issues 


4 Issues 


- Personnel Access Study 


I Issue 


I Update Issue 


Structures 


780 Hours 


2140 Hours 


- Midsliip Section 


2 Issues 


3 Issues 


- Shell Expansion 


1 Issue 


3 Issues 


- Calculation Report 


I Issue 


2 Issues 


Propulsion 


1500 Hours 


3520 Hours 


- Macliinery' Arrangement Draw ings 


2 Issues 


4 Issues 


- Endurance Fuel Calculations 


2 Issues 


3 Issues 


Etc... 


Etc... 


Etc... 



Table 9 Sample Task Estimates for an Auxiliary Ship^^ 



James Lyneis, “Calibration of System Dynamic Models", a presentation to MIT-Sloan course Application of 
System Dynamics, Cambridge, MA, April 17, 1998. 
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J—*— Shell Expansion 
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— Machinery Arrangement Drawings 
— Endurance Fuel Calculations 




23-Dec-88 



11 -Feb- 89 



19-Oct-89 



Figure 23 Sample Design Schedule Estimates for an Auxiliary Ship^^ 

This is a fundamental shortfall in the spiral concept. The spiral portrays the design process as linear. This is 
not the case. The process is better described as “quasi-linear.'’ The progression of tasks normally proceeds in a 
controlled, sequential manner. However, all design tasks within the spiral rely on input from and provide output to 
almost every other node of the process, As such, engineers and designers must have access to information (whether 
actual or estimated) from each design discipline and they must be acutely aware of the potential feedback effects 
caused by the changing output from tlieir own design products. As a result of tliese interrelationslups, tlie spiral is 
actually a network or '‘interaction mesh*' joining design nodes bv' physical relationships and information flows. ^ 
Take a simple example: power balance (Figure 24). Suppose the current iteration of a ship design does not 
acliiev'C desired speed. The current hullform results in required horsepower for speed. . . approximately a cubic 
relationship. Tlie required horsepower corresponds to a larger propulsion plant concept. . .a non-continuous step 
function. Tlie propulsion plant requires a larger machineiy^ volume and larger displacement. . . propulsion plant 
power density increases asvmiptoticallv . The hullfomi grow s to acconunodate larger propulsion stack 
length . . . volume growing as the cube of linear dimensional increases in plant size. Support systems also grow with 
the larger propulsion system and larger hullform. . . system weights increasing with hull parameters and propulsion 
plant horsepower. The larger hullform results in greater hull weight. . .hull weight increases as L“-L^ and hull 



Ron Nix, “T-AG9X PreliminaryVContract Design Estimates'*, Naval Sea Systems Command, Januarv' 16, 1987. 
Ibid. 

David Brown, “Naval Architecture*’, Naval Engineers Jounial . Janiiarv' 1993, pages 44-45. 
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surface area increases as L". The new hullfonn and displacement result in an increase in horsepower required for 
powering at the desired speed. . . hull resistance increasing in frictional resistance with increased displacement and 
vaning in wave and residual resistance by the choice of hull parameters. The result: increasing power to achieve 
speed can result in a need to furtlier increase power to achieve speed. The key to con\ ergence of tliis process will 
depend on the relationship of the various non-linear parameters and the choices of designers to manage feedback of 
those parameters. Also, note that the design process is impacted by many of the disciplines of the spiral (marine 
engineering, hydrodynamics, structural engineering, weight engineering, etc.) and did so in a non-linear sequence. 




Support System 



Figure 24 Simple Iterative Design Network 

Another e.xample of the design process as ‘‘quasi-linear'’ spiral is seen in the application of design s\ nthesis 
software. The Advanced Surface Ship Evaliuition Tool (ASSET) is a concept and preliminaty design s>nthesis tool 
used by the United State Nav\^ to balance and assess ^•arious naval ship concepts. The program is structured as 
presented in Figure 25. The figure shows how , like the spiral, ASSET proceeds sequentially tlirough a series of 
design tasks (called modules) and iterates solutions for a convergent design This progression leads to a linear A'iew’ 
of the design process. Figure 25 also show s a sample of the master parameter list (MPL.) The MPL is a product 
model database containing all design attributes used as input and generated as output by the ASSET modules. It is 
the interaction of the sequential modules with the MPL that creates dynamic, non-linear design beha^ ior similar to 
that seen in Figure 24. 

To demonstrate this behavior, consider the analysis of the DDG-51 in ASSET. The baseline ship has four GE 
LM-2500 gas turbines propulsion engines with 19220.4 kW each. This results in a total shaft power of 74,974 kW 
and a resultant maximum speed of 3 1 .2 kts. Suppose that a step decrease of propulsion power is proposed by 
replacing the current LM-2500 model 30 engines with smaller model 2 1 engines. The smaller engines proMde 
16032.5 kW each, 62,539 kW total shaft power and a maximum speed of 30.2 kts. The svmthesis of this change 
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requires 5 iterations of the design in ASSET. During each iteration, the ASSET modules modify ship charactenstics 
stored in the MPL and consider the characteristics non-convergent if the values change by more than 0. 1% from the 
pre\'ious iteration. Table 10 lists those characteristics for each non-convergent iteration that posed the greatest 
differential from the previous iteration. Note that the appendage module com erges faster then the others. Also, the 
auxiliary and weiglit modules are each limited by the same variable: lightsliip weight. The resistance module is 
most limited by effecth e horsepower (EHP) for only the first two iterations while EHP is most hmiting to the 
machineiy^ array for all iterations. Generally, the iterations demonstrate a variation of convergence rates among 
design disciplines, variations of limiting characteristics, and the coupling of design variables among disciplines. In 



other words, the process is non-linear. 



Module 


Iteration 1 


Iteration 2 


Iteration 3 


Iteration 4 


HULL GEOM 


GMT 


GMT 


GMT 


GMT 


HULL SUBDIV 


HULL ARR AREA 
AVAIL 


SHAFT ALLEY 
VOLUME 


SHAFT ALLEY 
VOLUME 


SHAFT ALLEY 
VOLUME 


DECKHOUSE 


AREA BEAM 


AREA BEAM 


AREA BEAM 


AREA BEAM 


HULL STRUCT 


HOGGING EM 


MIDSHIP MOI 


SAGGING BM 


SAGGING BM 


APPENDAGE 


SKEG PROJ 
AREA 


APPENDAGE 
DISP ARRAY 






RESISTANCE 


SHIP EHP 
ARRAY 


SHIP EHP 
ARRAY 


PRPLN SYS 
RESIST ARRAY 


PRPLN SYS 
RESIST ARRAY 


PROPELLER 


PROP RPM 
ARRAY 


PROP RPM 
ARRAY 


PROP RPM 
ARRAY 


PROP RPM 
ARRAY 


MACHINERY 


SHIP EHP 
ARRAY 


SHIP EHP 
ARRAY 


SHIP EHP 
ARRAY 


SHIP EHP 
ARRAY 


AUXILIARY 


LIGHTSHIP WT 
ARRAY 


LIGHTSHIP WT 
ARRAY 


LIGHTSHIP WT 
ARRAY 


LIGHTSHIP WT 
ARRAY 


WEIGHT 


LIGHTSHIP WT 
ARRAY 


LIGHTSHIP WT 
ARRAY 


LIGHTSHIP WT 
ARRAY 


LIGHTSHIP WT 
ARRAY 


SPACE 


DKHS ARR AREA 


OTHER ARR 


OTHER ARR 


OTHER ARR 




REQ 


AREA REQ 


AREA REQ 


AREA REQ 



Table 10 Limiting Characteristics for ASSET Iterations of a Propulsion Change to DDG-51 



A similar non-linear representation of design synthesis can be found in other design tools: GODDESS 
(Goverimient Defense Design for Sliips & Submarines), CONDES (Concept Design Suite) and HFDS (Hull Form 
Definition System.)^^ Thus, like tlie basic design spiral described previously, seemingly linear structures for naval 
ship design s> ntliesis are actually non-linear in nature. 



Whatmore and Wintersteen, A Review of Extant Design Tool Capabihties to Identify Common Design Tool for 
Future Collaboration, Naval Surface Warfare Center Carderock Division, Bethesda, MD, Febniaiv’ 28, 1997. 
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I 



MONOSC./MONOLA/MONOCV Modules 



Synthesis Section 




Inout^Output Section 



HULGEN 



EXPORT 



Analysis Section 



PERFORMANCE 



HYDROSTATICS 



SEAKEEPWQ 



SHIP RE Q 

_j SHIP COMMENTS 
J SHIP COMMENT TBL 

Q MISSION 

j SHIP TYPE IND 
J DESIGN MODE IND 
j ENDURDISPIND 
j ENDUR DEFIND 
J ENDURANCE 
J MAX SPEED 
J SUSTN SPEED IND 
J SUSTN SPEED 
J SUSTN SPEED POWER FRAC 
J ENDUR SPEED IND 
J ENDUR SPEED 
J AVIATION FAOLITIES IND 
j EMBARICED COMMANDER IND 
PAYLOAD AND ADJUSTMENTS 
J P^A NAME TBL 
J P*A SWBS KEY TBL 
J P*AWT ADD ARRAY 
_j P-AWT FAC ARRAY 
j P+AVCGKEYTBL 
J P^AVCG ADD ARRAY 
_j P^AVCG FAC ARRAY 
_j P+AAREAKEYTBL 
J P*AAREAADD ARPAY 
_j P+A AREA FAC ARRAY 
J P^AKW ADD ARRAY 
J P*AKW FAC ARRAY 

3 hull 

HULL FORM 
HULL FORM FACTORS 
_j HULL OFFSETS IND 
J HULL DIM IND 
J M'NBEAM 
J MAX BEAM 
J AREA BEAM 
J GMT 
J GMT/BREO 
J FREE SURF COR 
J FAST SHIP PARENT IND 
J FAST SHIP ADJUST ARRAY 
J SERV LIFE KG ALW 
J STABILITY IND 
J BULWARK H' 

J HULL FLAPE ANGLE 



Figure 25 ASSET Program Structure and Master Parameter List Example 
In order to properly represent the naval ship design process in a s>'stem dynamics model, there must be an 
accounting of the non-linear interactions seen in the design spiral. A method that can capture this behavior is the 
Design Structure Matrix (DSM.)^^^ First proposed by D. V. Steward in 1981, DSM is a graphically based technique 
to express design process information in a matrix form. The matrix structure shows design tasks by input and output 
relationships. These relationships can be found from physical requirements of engineering as well as procedural 
requirements and structures applied by design managers. 

Consider tlie design tasks discussed pre\iously (Table 9.) The tasks demonstrate a combination of sequential 
and concurrent relationships. Tliese relationships can be captured in a matrix. A possible matrix formulation for tlie 
tasks is shown in Figure 26. The row s are tasks in tlie design sequence with the corresponding columns showing 
those fields that pro\ ide input to the task in the row . The diagonal is assumed to be ‘‘0” as a single task should not 
be dependent on itself (note that tliis assumption may not be correct if the design task is itself a compilation of 
smaller tasks.) Each matrix element is represented as binar\\ However, it is possible to furllier refme the “strength” 



Naval Surface Warfare Center Carderock Divisioa “Getting Started & Tutorials: Adv anced Surface Ship 
Evaluation Tool (ASSET) Familv of Ship Design Svmthesis Programs”, September 30, 1997, page 3-29 and page 3- 
22 . 

Eppinger, Wliitney, Smith and Gebala, “A Model-Based Method for Organizing Tasks in Product Dev’elopment”, 
Working Paper, Massachusetts Institute of Teclmology, 1993. 
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of relationships by a percentage of input information required differential change of dependent row on mput column 
or other order of magnitude measure. Ideally, the sequence of rows should form a lower triangle, thus showing 
that tasks proceed sequentially from previous tasks. However, the non-hnear relationships of the naval ship design 
process result in both upper and lower triangle relationships. . .this is called couple development. The ability to 
perform effective concurrent engineering (i.e. maximize productivity and minimize rework) is dependent on the 
level of coupled development, the strength of those relationships, and the ability of engineers to select design lanes 
(initial design assumptions) that minimize iteration differentials. It is further possible to optimize a process by 
rearranging task sequences to minimize the upper triangle against the lower. Such optimization is particularly useful 
for reduction of design code, computational effort and design effort in sy nthesis of naval ship designs. Ov erall, 
DSM combined with a s>stem dynamics model provides an effective means to represent naval ship process 
dynamics. 
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Figure 26 DSM for Sample Design Tasks 



4.2 Design Disciplines 

With an enhanced understanding of the design spiral, it is necessary to restructure the basic sv stem dv namics 
project management structure to reflect the non-linear process seen in the DSM structure. Additionally, it is 
necessarv' to structure the design tasks in a manner that appreciates tlie multitude of design disciplines applicable to 
the design process and subsequent task accomplishment, without requiring a level of detail that precludes effective 
understanding and exploration (i.e. rninirnize the DSM structure.) Specifically, the structure must reflect the variety 
of design tasks within a single phase, the inter-relationsliips of those tasks, and tlie growth of tasks (as a function of 
necessarv^ design detail) from phase to phase. 

A causal loop diagram is developed to understand the structure that must be included in a naval ship design 
model. Consider the following situation: 

1. Initial iteration begins with a quantity of design tasks. 



Ibid. 

Tan and Bligh. "A New Approach to an Integrated CAD Metliod for Surface Ship Design”, Naval Engineers 
Journal , Januar> 1998, page 35. 
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2. Engineers and managers with specific know ledge of their design disciplines must communicate 
information related to their design tasking to the group in order to provide dependent design tasks with 
input data (establishing design lanes), 

3. Based on the level of organizational communication (ranging from disconnected to fully integrated 
design teams) and the imposed design constraints (such as design requirements and design margins), an 
engineer find that the initial assumptions made to proceed with the design may or may not be accurate at 
the end of the design iteration 

4. As a result of interaction. . .if communication is lacking or the design is not sufficiently constrained then 
the design tasks may be delayed due to competing variations in the initial design assumptions or fail 
entirely due to divergent tasks coupling. 



Figure 27 demonstrates this concept graphically. 




Figure 27 Generic Design Task Relationship 

The rate of design communication and, thus, the rate of design iterations is composed of both controlled 
iterations or "baseline freezes” (those designated instances in the design process during which all design elements 
are frozen to a common set of values) and free iterations (those communications of design change resulting from the 
direct communication of engineers or exchange of design characteristics with a common design product model.) 
'‘Baseline freezes” tvpically occur at predictable rates. An example of the these rates are shown m Table 1 1. A 
baseline freeze represents a complete design spiral and thus, a complete ship design: but a completed spiral may not 
represent a fully balanced or optimized design. Within the context of DSM, a baseline freeze would be a complete 
sequencing througli the design task matrix. Free iterations occur due to coupled development. Designers from a 
dependent task group communicate at some rate with otlier task groups and update infonnation to maintain accurate 
task data. A slow communication rate w ill naturally delay the design process. This fact has been noted by the 
method of ‘"over the wall” design. However, commimication at too quick a rate could be equally concerning. 
Specifically, an increased rate results in increased commumcation overhead Increased commmiication may result 
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in decreased time for productive engineering activities. Additionally, high variations in input data can result in 
instabilities in convergence rates. Iteration rates and communication rates impact the design model. 



Design Phase 


Typical Number Iterations 


Typical Duration 


Concept Design Phase 


10-100 


3-5 days 


Preliminary’ Design Phase 


4-8 


3-6 weeks 


Contract Design Phase 


2-4 


1-3 months 


Detailed Design Phase 


1-2 


1-3 years 



Table 11 Typical Design Iteration Issues and Durations'^^ 



Based on this beha\ior, it is possible to model the cycle time relationship of task accomplishment with 
respect to design interactions. Tlie follow ing assumptions apply to the development of tlie relationsliips; 

• Only first order relationships are modeled (i.e. hull performance is a function of hull geometr\\ but only 
tlirough the first order translation of hull geometry into seakeeping and resistance attributes) 

• Relationships are considered binary^ (1 or 0) regardless of the degree of relationship. However. 

• Relationsliips judged as existent (1) must be supported by direct physical properties (i.e. SWBS Group 
100 Weight is a direct function of Hull Geometry' parameters and Structural dimensions) or legal and 
management requirements (i.e. all aspects of the design process must provide inputs to the 
progranunatically managed design liistory'.) See Chapter 8.4 for a complete list of references used to 
develop relationships. 

4.3 Design Task Matrix 

Given the non-linearities of the design spiral and the vast quantity of design tasks accomplished during a 
naval ship design (a typical surface combatant design may have over 2,500 separate sliip drawings in detail design 
alone), it is necessary’ to aggregate the tasks into appropriate design nodes. Aggregation allows analysis of dynamic 
interactions and concurrency relationships relative to the design process, while maintaimng manageable quantity’ and 
quality’ for modeling. An analysis of design products (see Chapter 8.4) required at each phase of design (concept 
tlirough manufacturing) and for each system discipline show s that the sy stem disciplines can be grouped into 6 
nodes and 23 sub- nodes. Table 12 shows a listing of the nodes, sub-nodes and a designation code that will be used 
tlirouglioiit tlie remainder of this work and the design model to refer to tlie nodes. 



E.xtrapolated from interviews (see Chapter 8.2) and basic design resources (see Chapter 8.4). 
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Designation 


Node 


Sub-Node 


AO 


Programmatic Disciplines 




A1 




Program Management Tasks 


A2 




Requirements & Assessment Tasks 


A3 




Risk Mitigation & Coordination Tasks 


BO 


Systems Engineering 




B1 




Logistics & Reliability Engineering 


B2 




Design Integration & Specifications 


B3 




Producibility & Production Engineering 


B4 




Performance & Requirements Engineering 


B5 




Manning 


CO 


Hull Systems Engineering 




Cl 




Hull Geometry 


C2 




Weiglit & Stability’ Engineering 


C3 




Hydrodynamics-Resistance 


C4 




Hydrodynamics-Seakeeping 


C5 




Hydrodynamics-Maneuvering & Appendages 


C6 




Structural Engineering 


C7 




Space & Arrangements 


DO 


Machinery^ Systems Engineering 




D1 




Machinery^ Systems Design & Integration 


D2 




Propulsion Systems 


D3 




Electrical Systems 


D4 




Auxiliary' & Support Systems 


D5 




Deck. Handling & Aircraft Support Systems 


EO 


Mission Systems Engineering 




El 




Mission Systems Selection, Design & Integration 


E2 




Topside Design & Integration 


FO 


Cost Engineering 




FI 




Cost Estimation & Analysis 



Table 12 Design Process Nodes and Sub-Nodes 
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Requirements & Assessment 


Risk Mitigation & Coordination 
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Manning 


Hull Geometry 
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Analysis of the relationships of these task elements results in the DSM design matnx shown (Figure 28.) 
Figure 29 shows a complete network resulting from the matrix relationships. The outer ring of the netw ork 
represents the traditional, linear design spiral. The interactions represent the range of free iterations possible in the 
process. Chapter 5 discusses the specific approach used to combine the system d> namics process model with the 
DSM model. The remainder of this chapter addresses the logic supporting the DSM elements and the expected 
behavior resulting from the elements and nodes. 

Before preceding, note that the following assumptions have been made with respect to the DSM structure: 

• The baseline task elements (Table 14 through Table 38) are specific to the DDG-51 program. As such, 
elements for current surface combatant design programs may not be represented 

• The discussions associated with each task node (Sections 4.4 through 4.9) provides a justification for the DSM 
relath e to the DDG-51 task elements as well as highlighting current trends in tasks and interdependencies. 
Future applications of the DSM structure must incorporate dependency shifts resulting from those trends. 




Figure 29 Design Spiral “Interactions” 



4.4 Programmatics 

Programmatics represents the core tasks of eveiy^ naval ship design project. It may also be referred to as 
Acquisition Management. Programmatics contains tasks related to Program Management, Requirements Setting and 
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Assessment, and Risk Mitigation and Coordination. These elements support the creation of a design and acquisition 
program, management of the design and contract award oversight of the production design and construction, and 
engineering support to the operational forces throughout the life cycle of the ship. Specific programmatic tasks are 
required by DoD Instruction 5000.2 (Defense Acquisition Management Policies and Procedures) and DoD Manual 
5000.2 M (Defense Acquisition Management Documentation.) A complete listing of applicable directives is found 
in tlie Defense Acquisition Deskbook ( ]ntp:/Au\w.deskbook.osd. mil. ) Additionally, tasks are necessitated by good 
engineering and business practice such as maintaining a design history or managing scope growth. 

The elements of programmatics were under fire in recent years due to perceived inefficiencies. As tlie 
fundamental decision-making support systems, programmatic tasks have seen a natural growth in project 
deliverables. This growth correlates to increasing teclmological design risk and pressure to decrease design cost (see 
discussion of externalities in Chapter 2.) The result is increasing time required to prepare documentation (Table 13.) 
Figure 30 shows task efforts (averages for 45 Navy, ACAT I design programs) expended for key programmatic 
deliverables. As the key inputs to program milestones, there has traditionally been a need to produce significant 
portions of tlicse documents prior to each review stage, which may include as many as ten different review and 
approval levels. The combination of multiple decision layers and increasing programmatic efforts is \iewed as a 
key factor contributing to the growth of the design cycle. 



Ship Program 


Prcliminar\' Design 


Contact Design 


DDG-993 


N/A 


1,454 


CG-47 


1.818 


8,147 


DDG-51 


2,696 


23,654 



Table 13 Programmatic Man-hour Effort Trends'®^ 



William Ball, '‘DoD Acquisition Policy and the Effect on Naval Ship DcsigiC, Society of Naval Architecture and 
Marine Engineering, February 25, 1992, page 7-5. 

Ship Design Group, Ship Design Project Histories: Volume I, II and III , Naval Sea Systems Command, 
September 1978, May 1986 and August 1996. 
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Figure 30 Average Programmatic Documentation Effort^^^ 

To counter these trends, significant changes were implemented with respect to programmatics. As part of 
acquisition reform iniuatives (see Chapter 1.11), contract specifications, programmatic deliverables and design 
reviews were modified to remove redundancies and outdated requirements. In particular, program managers are 
granted greater authority to reduce documentation requirements and wai\'e redundant design reviews entirely. These 
changes have significant impacts (positive and negative) on design programs. For instance, the LPD-17 contract 
design effort was negatively impacted when a directive to reduce contract specifications was implemented well into 
the design process. Although tlie effort reduced contract deliverables (reduction from 1,452 to 327 specifications), 
thus impro\ing efficiency in lead ship design, contract design efforts were delayed se\ eral montlis to implement the 
reform (the effort was referred to as “triage”. )^^^ Conversely, reforms allow programs, such as the current DD-21 
program, to realb.e improved management efficiency and reduced review periods. These cases indicate that 
implementation of programmatic reforms may dynamically impact a project. 

In order to simulate programmatic fluctuations within the design model, the following assmnptions w ill be 

made: 

1 . Total programmatic requirements (number of tasks at each design pliase) are fixed initially for the model 

2. A capability to generate random and/or specified growth and decay of programmatic tasking is included 

Values for baseline productivity- and task levels are provided in Chapter 8.5. 



RADM Roger B. Home, “Concept to Commissioning Improving the Ship Design, Acquisition and Construction 
Process: Strategic Plan”, Naval Sea Systems Command, Washington. DC. June 1991, III-2.3. 11. 

Fireman, Fowler, MeIntire and Wilkms, “LPD 17: In the Midst of Refomi”, Naval Engineers Journal . May 1995, 
page 267. 

108 Dennis Mahoney (USN), former DD-21 Program Manager, interviews during Spring 1998. 
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4.4.1 Program Management Tasks 

Program management centers on five key areas; planning, controlling, organizing, staffing and leading. 
Planning includes all those acthities associated with the acquisition strategy and program schedule. The major task 
element for program management in a modem ship design program is the Acquisition Program Baseline (APB). 

The APB establishes the metrics to measure perfomiance, cost and schedule for the acquisition program and 
includes objective and threshold components. The APB is a living document that is adjusted and acted upon based 
on the influence of design changes, w arfare requirements and schedule pressures. The APB is the primaiy^ 
documentation for review and approval (S AR and DAES.) The APB development and approval process is 
demonstrated in Figure 63. Specific instructions for preparation of the APB are found in DoD Directive 5000.2. 

Controlling tasks are those elements necessary to monitor conformance of program performance to the 
guidance of authorities and the APB. The use of Cost/Schedule Control System Criteria (C/SCSC) may be utilized 
to “detect a deviation from the plan, (acthate) a control mechanism to bring the system back into line.”^^^ 
Specifically, controlling requires continual audit of program processes to monitor and correct process performance. 

Organizing and staffing involve the management of personnel and manpow er budgets with respect to the 
design process needs. This is a major s> stemic force in the design process. As such, it is explicitly modeled beyond 
tasking requirements (see Chapters 5.4 and 5.5.) 

Finally, leadersliip is the major function of the program management staff. The ability to clearly 
communicate desired program direction, goals and needs is critical to program performance. Leading the program 
entails continuous information gatliering and evaluation with respect to the forces acting to control the program (see 
Chapter 2). As a result of the program managers perceptions of those forces, he or she must respond by marketing 
the good aspects of the program and addressing concerns to responsible autliorities. In a teaming environment, as 
proposed by IPPD/IPT. program leadership means the ability to establish and maintain consensus. A program 
manager is by definition the leader of the design program, and it is his or her continuous role (and tlius tasking) to 
lead and guide a successftil acquisition program. To implement leadership over all aspects of the project, program 
management will naturally require input and output connections to all design disciplines 



Defense Management College. “The Program Manager's Notebook*’, Fort Belvoir, VA, June 1993. 
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Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Acquisition Program Baseline (AP) 


1 


1 


1 


1 


1 


1 


1 


Acquisition Strategy 


1 


1 


1 


1 


1 


1 


1 


Acquisition Decision Memorandum (ADM) & 
Defense Acquisition Executive Summary (DAES) 


1 


1 


1 


1 


1 


1 


1 


Program Management 


1 


1 


1 


1 


1 


1 


1 


Milestone Preparation and Exit Critena Satisfaction 


1 


1 


1 


1 


1 


1 


1 


Security & Security Protection Strategy 


1 


1 


1 


1 


1 


1 


1 


Legal Issues Analysis 


1 


1 


1 


1 


1 


1 


1 


Treaty Compliance Assessment 


1 


1 


1 


1 


1 


1 


1 


SHAPM Support & Special Studies 




1 


1 


1 


1 


1 


1 


Design History 




1 


1 


1 


1 


1 


1 


Design Site Management 






1 


1 


1 


1 


1 


Hull Engineering Task Group Support 






1 


1 


1 


1 


1 


Machinery Task Group Support 






1 


1 


1 


1 


1 


Deaqn Control 










1 


1 


1 



Table 14 Program Management Tasking 

Based on analysis of the DDG-51 program and other surface combatant projects, a general listing of program 

management tasks is developed. 

Table 14 shows the appropriate design phase during wliich specific program management tasks are activated. 
It is assumed that tasks are updated at each design stage. The list is not all-inclusive (nor are later hsts in this 
chapter), but does represent those primary' task elements required by directive or good engineering and management 
practice (see Chapter 8.5.) For purposes of the design model, the given quantity' of tasks (along with total 
programmatic man-hours expended) provides sufficient aggregate detail to model process behavior. With respect to 
the DSM structure, the command and control nature of program management necessitates complete input from and 
output to all design disciplines. As such, the row and column is unity' (see Figure 28.) 

4.4.2 Requirements Setting and Assessment 

The second program task element is tlie interface between the designers and the warfighters: requirements 
setting and assessment. The primary' concern of requirements is the definition of the defense-technical problem and 
translatmg tliis problem into a potential design. Chapter 1.12 specifically addresses the current mechanisms being 
applied to improve problem definition and translation. Additionally, there are a number of specific design 
deliverables that relate to those mechanisms. The Mission Need Statement (MNS) and Operational Requirements 
Document (ORD) are the initial documents produced in tliis discipline. The MNS in a non-sy stem specific 
statement of operational capability'. Tlie ORD fomially states warfighter objectives and minimum acceptable 
requirements for operational effectiveness of a proposed ship concept and its associated sy stems. Based on the 
requirements of the MNS and ORD, an AoA (fomierly COEA) study' is performed to analy'ze potential sy stem 
options SL .isfying the requirements. The AoA as defined here is not the act of concept engineering analysis, but 
rather the accumulation of infonnation developed by specific engineering disciplines in response to the stated needs 
of the MNS and ORD. In other words, the AoA is a document or task requirement, not a process. Instead concept 
and preliminary' design arc the processes by which AoA tasking is implemented. Figure 61 , Figure 62, and Figure 
64 show specific processes by which these documents are prepared and review ed. Tlicse requirements and post 
engineering assessments are continually audited to ensure the design meets tlie needs of operational forces. 
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When deficiencies are discovered the program manager has three primaiy options: modify the mission 
requirements, re-initiate the design to achieve the stated need or introduce an engineermg change to achieve the 
stated need Modification of mission needs is a relatively detailed process, but can be effective in the veiy early 
stages of design. This is particularly true during concept design if the design community (in conjunction with AoA 
tasking) is given an opportunity to present operational forces with specific design trades enabled by requirement 
changes . The approaches presented in Chapter 1.1.2 demonstrate the effectiveness of this approach. If operational 
needs cannot be changed then the design may need to be re-initiated. There are numerous examples of this 
approach in tlie last few years as a result of changes in defense doctrine and force structure. For instance, the DDG- 
5 1 Fliglit II A program is a direct result of a need to produce substantial improvements to the DDG-51 program 
following decommissionings of numerous combatant ship classes during the early 1990's. This option is not 
practical miless the design process is still young (the DDG-51 concept design process lasted four years for this 
reason) or the requirements changes preclude reasonable design modification within the current program (DDG-51 
Flight IIA.) When changes are moderate, then engineering change proposals (ECPs) may be used. Once again, 
early introduction of ECPs is preferred. Due to the long duration of naval ship design projects, it is inevitable that 
changes are required. Tliese changes hav e well documented negative impacts on the design process (see Chapter 
1.1.2.) Tliere are methodologies which can minimize the impact of design change including: Open Architecture and 
Modularity. Ultimately, the program manager must decide whether the timing and performance gains of a given 
design change outweigh the impacts to schedule and cost. 

For the purposes of the naval ship design model, these tasks and behaviors are incorporated as follows: 

1 . Tasks profiles are set per those listed in Table 15 

2. ECPs are introduced by random and/or specified task growth to the initial tasks 

3. Tlie fraction of task growth from ECPs is directly determined by the first order impacts of the scope 
growth being introduced (i.e. a design with open architecture would see a substantially smaller task 
fraction increase than a design without change mitigation mechanisms.) 



Like tlie structiue for program management, requirements setting indicates a direct output to all design tasks 
and assessment of those requirements requires input from all tasks. Tlius, tlie DSM structure is fully populated. 



TasK Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Decision Coordination Paper (DCP) 


1 


1 


1 


1 


1 


1 


1 


Selected Acquisition Report (SAR) 


1 


1 


1 


1 


1 


1 


1 


Congressional Data Sheet (CDS) 


1 


1 


1 


1 


1 


1 


1 


Mission Need Statement 


1 


1 


1 


1 


1 


1 


1 


Operational Requirments Document (ORD) & Requirements Setting 


1 


1 


1 


1 


1 


1 


1 


System Concept Paper (SCP) & Design Review/Report 


1 


1 


1 


1 


1 


1 


1 


System Threat Assessment 


1 


1 


1 


1 


1 


1 


1 


COEA/Analysis of Alternatives 


1 


1 


1 


1 


1 


1 


1 


Engineering Change Proposals (ECP) & "Externar Change Requests 












1 


1 



Table 15 Requirements Setting and Assessment Tasks 



MIT Course 13.64, “CVX Product and Process Plamiing", Massachusetts Institute of Teclmologv, Cambridge, 
MA, Summer 1997, page 70. 
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4.4.3 Risk Mitigation and Coordination 



The final category of programmalics is that set of tasks which provides analysis of potential program risks 
and coordinates technology development with other defense programs. Primary tasks in this category are: 
Development Test and Evaluation (DT&E), Test & Evaluation Master Plan (TEMP), Live Fire Test & Evaluation 
(LFT&E) analysis. Safety analysis and coordination efforts for Research, Development, Test and Evaluation 
(RDT&E). DT&E determines the potential variabihty in effectiveness, cost and schedule associated Mth 
technologies under consideration for tlie design. If the technologies are too risky for consideration, fail-back options 
are explored to allow the design to proceed. DT&E changes can impact the design rates through the introduction of 
delayed tasks (technologies maturing behind schedule) or scope change (transition of the program to the fallback 
position or introduction of a newly maturing technology.) Even after specific technologies are introduced into the 
design, it is necessaiy^ to develop a schedule to evaluate the effectiveness of the technology as integrated in the ship 
design. Specifically, the TEMP and LFT&E provide the structure to test sy stem effectiveness. As known and 
perceived risks relative to the technology or capability are disclosed, the plans must adapt. An increasingly 
important method of risk reduction is coordination of RDT&E w ith other programs. In particular, early R&D 
projects must be monitored to ensure compatibility with ship design development and mission needs. For more 
ach anced technolog>^ programs. Ship Acquisition Managers (SHAPMs) must coordinate efforts with Participating 



Managers (PARMs). Once again, changing technolog>' schedules and capabilities may impact the design process. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Risk Assessment 


1 


1 


1 


1 


1 


1 


1 


Programmatic Measures of Effectiveness Analysis (Cost Schedule & 
Performance Risk Analysis) 


1 


1 


1 


1 


1 


1 


1 


DT&E Report 


1 


1 


1 


1 


1 


1 


1 


Environmental, Safety & Health Evaluation 


1 


1 


1 


1 


1 


1 


1 


Technology & Industrial Capability Assessment (Commercial & NDl 

Evaluation & Status) 


1 


1 


1 


1 


1 


1 


1 


Cooperative Opportunities Assessment 


1 


1 


1 


1 


i 


1 


1 


Integrated R&D 


1 


1 


1 


1 


1 


1 


1 


Test & Evaluation Master Plans (TEMP) 


1 


1 


1 


1 


1 


1 


1 


LFT&E Waiver Certificate 


1 


1 


1 


1 


1 


1 


1 


LFT&E Report 


1 


1 


1 


1 


1 


1 


1 


Computer Applications & Support. Information Technology Architecture 


1 


1 


1 


1 


1 


1 


1 


Information Technology Statutory Compliance (Information Technology 
Management Reform Act (ITMRA), Government Performance and Results 
Act (GPRA), Paperwork Reduction Act (PRA)) 


1 


1 


1 


1 


1 


1 


1 


System Safety Study 




1 


1 


1 


1 


1 


1 



Table 16 Risk Mitigation and Coordination Tasks 

For tlie purposes of the naval ship design model, these tasks and behav iors are incorporated as follows: 

1 . Tasks profiles are set per those listed in Table 1 6 

2. Clianges resulting from technology changes are introduced b\' random and/or specified task growth to the 
initial tasks 

The DSM structure for risk mitigation deviates slightly from previous programmatic tasks. Process flows 
indicate that although risk tasking is performed for specific engineering disciplines (hull, machinerv’, payloads, 
system, cost), the risk analysis information is delivered tlirough program management and requirements rather tlian 
directly to the responsible disciplines. In this manner, risk mitigation and coordination acts as an information 
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control gate dunng feedback of design attributes. As assessments of requirements against presented design 
parameters are assimilated the elements of risk mitigation incorporate those values. If specific nsk analysis 
indicates concerns or necessary coordination, then modifying information will flow back to those disciplines that 
perform physical design (hull geometry, mechanical s\ stcms, mission s>stems, etc.) 

4.5 Systems Engineering 

The second design process node is s>stems engineering. It is important to differentiate systems engineering 
as discussed in Chapter 3 from this process node. System engineering as discussed previously represents the 
overarching optimization of cost, effectiveness and schedule to meet a need. In this context, the naval ship design 
process is a subset of systems engineering. However, within naval ship design is an alternative systems engineering 
definition. In this context, s> stems engineering represents those engineering disciplines required to integrate 
specific ship design components (hull sy stems, mechanical sy stems, and combat sy stems), to analy'ze the integrated 
components in the sy stem (Integrated Logistics Support (ILS), contract specifications, producibility, manning) and 
to compare the sy stem performance against requirements (mission effecti\ eness.) In tliis context, sy stems 
engineering has evolved over the last 40 years to become a key clement of the design process. Initial fonnalization 
of systems engineering began in the 1950’s on the first balhstic missile programs. During the 1970’s, sy stems 
engineering achie\ ed true maturity' in the Aegis Weapons Program (1970's) under the guidance of ADM Wayne 
Meyers (USN retired.) During an interx iew with ADM Meyers^ he made tlie following comments regarding the 
impacts of systems engineering on the overall design process: 

1. “Warsliips are inherently inefficient design exercises.” Due to the scope of surface combatant design 
projects, indi\idual design components are rarely optimized in the context of system impacts. For 
instance, component optimization generates vast numbers of supplier-vendors. A large vendor base 
requires complex supply chains which dc-optiniize ILS and life cycle cost. Until effective system 
optimization is realized (see Chapter 1.1.2). component development will continually generate 
divergences in sy stems de\ elopment. 

2. “Program managers don't know, only perceive, the true status of the fiscal, technical, temporal vectors.” 
The goal of the program manager is to focus the project tow ards con\ ergence. However, uncertainties in 
information, vanations in cost, and delays in progress cause the vectors to diverge. In sy stems 
engineering, this is even more critical as the integration of components is constantly \'ary ing w itli the 
variable schedules and complexities of those components (Figure 23 and Tabic 9.) Coupled productivity 
and v ary ing development rates produce delays in sy stems development. 

3 . “Know ledge . . . Engineering, Cost, etc . . . must be accumulated and tapped to facilitate sy stems 
integration.” Systems engineering is the cap-stone of the naval engineering process. To effectively pull 
together the elements of the system, time and patience are necessary. Unfortunately, time is also the 
enemy of the design process. . . time generates changing requirements and changing technologies. To 



ADM WayTie Meyers (USN retired), interview on November 14, 1997, Arlington, VA. 
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understand s> stems engineenng one must acknowledge the impact of time. . early work is undone, later 
w ork will require iteration back to the component level, and ver\^ late work will introduce scope 
increases which can diverge the program. 

Baseline (DDG-51) task levels and productivity levels for Systems Engineering are presented in Chapter 8.5. 

4.5,1 Logistics and Reliability Engineering 

Integrated Logistics Support (ILS) and Reliability, Maintainabihty' and Availability (RMA) assessment are 
the disciplines that may most greatly determine tlie life cycle cost and operational effectiveness of the ship design. 
ILS is a management and technical approach that integrates support considerations into system and equipment 
design. Support requirements are determined by readiness objectives, current and planned supply chains (underway 
replenishment, storage, supply overhead, packaging, handling), maintenance plans, manning levels, and training 
pipelines. RMA (also known as RAM) is a complement to ILS. RMA analysis determines the level of ILS required. 
Specifically, RMA assesses operational functionally for the sliip, redundancy versus rehability, and the ease of 
recovery' of systems that do fail (relative to ILS and maintainability.) 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Integrated Logistic Support & Maintenance Analysis 


1 


1 


1 


1 


1 


1 


1 


Reliability, Maintainability and Availability (RMA) Assessment 


1 


1 


1 


1 


1 


1 


1 



Table 17 Logistics and Reliability Engineering Tasks 
RMA and ILS are highly coupled disciplines. As such, it is not unreasonable to assign a value of 1 to the 
diagonal for DSM (see Chapter 4.1.) However, the value of 0 is assigned to maintain consistency with DSM 
methodology. Input values are required from those disciphnes that impact maintenance, reliability and support 
including, requirements, manning, hull structures, arrangements, mechanical and mission systems. The results of 
ILS and RMA feed programmatics for action, if necessary'. Additionally, results provide input to producibility' (ILS 
has a first order impact on production methods) and to performance (RMA is an input for Ship Vulnerability' 
Modeling (SVM) and operational effectiv eness measures.) 

As w ould be expected. ILS and RMA should be started from tlie initiation of the design in order to achieve 
the greatest leverage over life cycle cost (LCC). Table 17 shows the progression of ILS and RMA tasks. Past design 
programs minimized the early ELS and RMA effort. This can be seen by the small man-months per task during 
concept and preliminaiy design shown in Chapter 8.5. Given current ILS trends, there is increased need for early 
analysis. Figure 3 1 shows the exponential growth experienced in ILS o\ erhead measured as increasing parts listings 
(APL’s.) With increasing parts and supply trains, ILS becomes an increasingly greater fraction of LCC. As shown 
in Figure 32, the primary' ILS components (manning and maintenance) constitute almost 60% of the LCC. Recent 
efforts to coimter the trend (such as Affordability Through Commonality (ATC) and open systems architecture) 
show' promise. Applied to current design programs, these efforts provide substantial cost sa\ings, but require greater 
man-hour efforts in early design. For the baseline design model, DDG-51 ILS task efforts are used. However, 
future "w hat-if ' scenarios should reflect increased efforts in early stage design. Tliis would provide program 
managers with a comparison of life cycle cost savings \ ersus the impact on schedule and resources. 

76 




Figure 31 Trends for Applicable Parts Lists (APL’s) for Surface Combatant Designs^^^ 




Maintenance 

21 % 

Figure 32 Life Cycle Cost Components for Typical Naval Ships“^ 

4.5.2 Design Integration and Specifications 

Design integration and specifications are the means by which the design achieves system definition and seeks 
to maintain designed performance in subsequent iterations. In the early stages of design, s> stems engineering 
decisions are meant to define the overall ability of concepts to satisfy expectations for total s> stem effectiveness. As 
specific ship components (hull, prime movers, combat system elements) are considered in the design, these elements 
must be optimized relative to one another and relative to mission requirements. As design iterations are generated, 
there may be the tendency* of component engineers to continuously change in response to changing input 

Todd Can’, Naval Sea Systems Conmiand, inteniew on August 27, 1997, Arlington, VA. 

Ryan and Jons, '‘Improving the Ship Design. Acquisition and Construction Process", Association of Scientists 
and Engineers, 28^ Annual Teclinical Symposium, 11 April 1991. page 13. 
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information from other component elements. Without mechanisms to manage these changes, it is likely that the 
design would diverge. This is the role of systems integration. Througli the use of margins (see Chapter 1.1.3) and 
configuration control, design managers restrict the degree of change permitted over time. Configuration control 
(managed by means of a baseline 3-D product modek equipment lists, performance specifications, mihtan' 
specification, issuing arrangement drawings, etc) provides a design baseline that “freezes" those aspects of the 
design viewed as satisfactory with respect to the requirements. 

In later design stages, design integration matures beyond configuration specification to component 
specification. Earlier discussions (see Chapters 3.3.1 and 4.4) demonstrate the changing roles of contract 
specifications in the design process. Howe\ er, the selection of components and their exclusion from further design 
change must take place in the design process, whether dictated by the govermnent during contract design or b\* 
industiy^ in functional design. Ultimately, the design must be specified in order to allow' production. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Systems Engineering, Design Integration & Configuratton Control 


1 


1 


1 


1 


1 


1 


1 


Ship & Purchase Specifications, GFE/GFI & CDRLs 




1 


1 


1 


1 


1 


1 


Specification Design History Input 




1 


1 


1 


1 


1 


1 


GFE'GFIA/FI Specification 






1 


1 


1 


1 


1 


Design Control 










1 


1 


1 



Table 18 Design Integration and Specification Tasks 
Table 18 provides a listing of the specific design tasks associated with design integration and specification. 
Note tliat tliese task effort profiles (Chapter 8.5) would likely change for a current design program to reflect a 
changing government to industry design transition point (see Figure 5). However the task elements (with perhaps 
different names) would still remain. 

Tlie input requirements for design integration include tliose elements of the process that are specific to design 
definition (hull, structures, marine systems, combat systems.) The design integration tasking receives the inputs of 
current design parameters and outputs constraints to the program manager for implementation. 

4.5.3 Producibility and Production Engineering 

Producibilih' and production engineering is the consideration of industrial capabilities relative to ship design 
and construction Tliis requires both the assessment of industrial capabilities relative to technologies incorporated in 
the design and inclusion of “design for production'’ elements in the design. To tlie first requirements, the industrial 
base necessarv' to support naval ship design and construction must be assessed. For instance, tliere only a few 
shipbuilders witli facilities, knowledge and skills av ailable to produce specialized huUforms (such as submarines) or 
to test advanced combat sv stems (such as the Aegis Weapons Sv stem.) The selection of specific ship design options 
(such as materials, size, weapon sv stems, etc) will naturally reduce the field of potential builders. Tlie introduction 
of new technologies may further reduce the capable industrial base. It is a necessaiy' task of design managers to 
understand tlie impacts of technolog> and design on the shipbuilders. Secondly, design for production must be 
included to achieve the cost goals described in Cliapter 1. 1.3. Specifically, the design must: 

1 . Dev elop a build strategy and product work breakdown structure. 
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2. Assess the design against the production process 

3 . Incorporate appropriate producibility enhancements. 

It IS apparent that this process of design for production is itself a closed loop system that seeks to optimize cost and 
production effectiveness relative to military effectiveness. 

It is noted tliat design for production considerations were not adequately included in past designs. Due to 
requirements for competition, US yards have not been able to incorporate producibility to the extent necessaiv’ to 
realize savings. Consider Table 19. In foreign yards, designs are specifically tailored to the capabilities of the yards 
and their workers. As such, e\^en in countries where workers are paid more, the labor required to produce a ship and 
the total labor costs are less. Consider the design task elements for the DDG-5 1, and hence the baseline naval ship 
design process model, shown in Table 20. The ship work breakdow n structure was not formalized until late in the 
process. Again demonstrating tlie lack of producibility consideration in the fmal design. 



Productivity 


Japan 


Korea 


Germany 


us 


Employee-Days/Ship 


45,000 


99.000 


65,000 


100.000 


Hourly Compensation (1990 US Dollars) 


16.0 


7.8 


26.5 


15.6 


Total Labor Charges ($ million) 


5.76 


6.17 


13.78 


12.48 



Table 19 Shipyard Productivity Comparison for Comparable Ship Designs^^^ 



Tliere are significant efforts to change this trend and to incorporate producibility much earlier in the design 
process. For instance, the LPD-17 hiillform design was enhanced w ith large flat plate construction, single cuiv ature 
midbody and an elliptical bulbous bow (no fillet).^ These enhances are a step in tlie direction of enliancing 
producibility. Current programs will furtlier improve producibility by incorporating sliipbuilders at the earliest 
stages of design. 

To maximize the leverage of producibility on cost, a ship design must be optimb.ed from the concept phase 
onward not only for mission needs and operational cost, but also for production schedule and construction cost. 
Producibility tasking may take several forms, but two are generally obseiv ed. First, producibility is assessed relati\'e 
to fabncation, arrangements and materials. For those designs that are optimized for a particular shipyard’s 
capabilities, ship arrangements (outfitting, block sizes, etc) and materials and fabrication (common material 
catalogue, limiting complex shape geometry ) enhance productivity for the shipbuilder. Impro\ed producti\ity 
means lower costs, better quality and shorter production schedules. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


industria! Facilities Design and Industrial Base Assessment (BASE) 


1 


1 


1 


1 


1 


1 


1 


Producibility. Fabrication & Materials Assessment 




1 


1 


1 


1 


1 


1 


Ship Work Breakdown Structure 








1 


1 


1 


1 



Table 20 Producibility and Production Engineering 



Rost and Tighe, 1992 Shipyard Costs and Capabilities , Center for Na\al Analysis, Alexandria. VA. 

Fireman, Fowler, Mclntire and Wilkins, ‘'LPD 17: In the Midst of Reform”, Naval Engineers Journal , May 1995, 
page 275. 
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However, competitive requirements of contracts necessarily limit the level of producibility optimization that 
can occur. For this reason, a second method of producibiliU' assessment has been developed: Generic Work 
Breakdown Structure (GWBS). As its name implies, the method provides a generic method of assessing 
producibility. The method is centered around group technology construction and organization of design elements 
into families of structures and components.^ For early design (pre-contract award) the method provides a tool to 
assess production impacts of design decisions and to minimize costs where possible. 

For the design model, Table 20 provides the baseline progression of design tasks. Again, current design 
programs will see variations in the timing of design tasks and growth in the lev els of producibility tasks. 
Dynamically, producibility incorporates specific slhp characteristics (liuU geometrv\ structural design, arrangements, 
machinery and payload components) to assess construction impacts. Tlie output of producibility is assessed at tlie 
management level. Additionally, producibility is a key input factor to cost assessment. 

4.5.4 Performance Assessment and Requirements Comparison 

Performance assessment includes modeling design characteristics as a total s>stem, calculating ship's 
performance based on total ship design parameters, and assessing tlie mission effectiveness relativ e to requirements. 
Performance assessment has improved in recent years through improv ements in computer modeling capabilities. 
Specifically, Survivability and Vulnerability Modeling (S VM), Electromagnetic Workstation (EMW) models. 
Leading Edge Advanced Prototyping for Ships (LEAPS), and others provide increasingly robust environments to 
test s)'Stem performance and effectiveness. These models are the initial steps of a trend towards simulation based 
design (SBD.) Although, most levels of performance assessment still require physical modeling (such as hullform 
testing in towing tanks), improved computer modeling will eventually provide the means to test all performance 
requirements in the virtual environment. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Survivability & Vulnerability Assessment 


1 


1 


1 


1 


1 


1 


1 


Concept Performance 


1 


1 


1 


1 


1 


1 


1 


Damage Control System Design 


1 


1 


1 


1 


1 


1 


1 


NBC (CBR) Defense 


1 


1 


1 


1 


1 


1 


1 


Combat System Performance Assessment 


i 


1 


1 


1 


1 


1 


1 



Table 21 Performance Assessment and Requirements Comparison Tasks 
Table 2 1 shows a progression of performance tasking that w as performed for the DDG-51 program. The DD- 
21 program will include mission effectiveness assessment and task efforts such as: Extended Air Defense Simulation 
Model (EADSIM), Surface AAW Multi-Ship Simulation (SAMS), Naval Air Battle Engagement Model (NABEM 
11), Radar Analysis Model (RAM), AS W Programs Surface Ship Engagement Model (APSURF), and Genenc Sonar 
Model (GSM) 



Storch, Hamition, Bunch and Moore, Sliip Production . Society of Naval Arcliitects and Marine Engineers. Jersey 
City, NJ, 1995, page 60. 

Myles Hurwitz, ‘'Leading Edge Advanced Prototyping for Ships (LEAPS): an Integrated Architecture for Early 
Stage Ship Concept Assessment Software”, David Taylor Research Center, Betliesda, MD, 1997. 

DD-21 Program Website, http:/Avv\w.navsea.navy^mil. 
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Like other systems engineering disciplines, performance assessment requires input from all design definition 
disciplines. However, the output of assessment is often provided directly to designers. This is particularly true in 
the real-time design and selection of specific design characteristics such as arrangements, hull and deckhouse 
configuration and topside arrangement of combat systems. 

4.5,5 Manning 

Mamiing assessment and definition is the final discipline of sy stems engineermg. Manpower studies begin 
with comparative estimates of ship functions to similar ship designs. Later studies provide detailed manning studies 
based on functional breakdowTis of manning requirements. As manning levels are established for specific ship 
watch stations, human engineering are conducted to optimize human performance relative to mission performance. 

For many years, manning was \iew ed as a non-constraining attribute. Namely, sliipboard manpower was 
viewed as unlimited. Damage control, condition I w atch stations and maintenance requirements often drove 
manning levels well above those levels required for daily operations. However, the fiscal need for reduced 
operational costs and the political desire to limit human exposure to threat environments now results in imposed 
manning levels. If this trend continues, maiming assessment becomes increasingly important to both s\ stem and 
component design. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Manpower Estimate 


1 


1 


1 


1 


1 


1 


1 


Manning Study 


1 


1 


1 


1 


1 


1 


1 


Ship Manning Document 




1 


1 


1 


1 


1 


1 


Human Systems (Factors) Engineering 




1 


1 


1 


1 


1 


1 



Table 22 Manning Assessment Tasks 

Table 22 show s the progression of manning tasks. Tliese tasks require input primarily of those ship 
characteristics that impact human engineering and mamiing requirements including: ship arrangements and sizing, 
machiner}' s\ stems and combat sy stems. Early output from manning impacts sizing of the hull, payloads and 
auxiliaiv' systems. Later output provides specific requirements for accommodations (arrangements), machineiv' 
system modifications for human support and second order changes (changing maintenance requirements or selection 
of new' equipment items) tlirougli program management. 

4.6 Hull Engineering 

The hull engineering node is itself a significant systems engineering effort. Na\ al architects, the primaiv' 
participants in hull engineering, often claim the title of the "world's first systems engineers. Specifically, hull 
engineering must balance weight, buoyancy, area, power and resistance w hile maintaining adequate static and 
dynamic stability and strength, both in intact and damaged conditions. Specific design spirals are developed to 
balance these characteristics. For instance, the MIT Math Model - FFX'^^, balances hull characteristics, deckhouse 

Tibbitts and Keane, "Naval Ship Design in the 2T^ Centuiy '’, Society of Naval Architects and Marine Engineers, 
Jersey City , NJ, 1993. 

Brown and Welsh, MIT Math Model - FFX, Massachusetts Institute of Teclmolog\' course 13.412, fall 1996. 
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v olume and power for fixed inputs of marine sv stems, combat payloads, mission requirements, and maiming. The 
original design spiral dev eloped by Prof Evans performed a similar optimization for commercial ship designs. A 
specific examination of equations and physical relationships for hull design and engineering are beyond the scope of 
tiiis work. Rather, the nature of the component design disciplines and tlieir purposes relative to the design process 
are discussed. 

It is important to note a general cliaiige in hull engineering disciplines over the past decades. In the past, 
arrangements and hull geometry' and powering were often separate exercises from hydrostatic and hydrodynamic 
analysis. Although it was possible that the same indiv idual or group of individuals might perform the design and 
analysis tasks, the considerable manual effort required to perform tliose tasks would necessarily cause them to be 
performed independently. This fact is apparent in IDEF charts and design spirals depicting very linear and distinct 
nodes. For instance. Prof Evans design spiral generates a basic ship design from^^^ : 

1 . Proportions and Powering Estimates 

2. Lines and Body Plans 

3. Hydrostatics and Bonjeans 

4 . Floodable Length and Freeboard 

5. Arrangements 

6. Structures 

7. Powering Light Ship Weight Estimates 

8. Capacities, Trim and Intact Stabilitv' 

9. Damaged Stability 

10. Comparisons to Cost and Owners Requirements 

11. Nexl Iteration... 

This indicates an algoritlim by which design disciphnes are separated or design tasks are linear. However, today’s 
design tools are allowing seamless design and analysis with real-time iteration and feedback. For instance, hull 
geometrv' software often includes modules to create hullforms, assess resistance, generate hydrostatic properties, 
assess maneuv erability and detennine seakeeping. These integrated packages allow a single designer to 
inmiediately see the impact of a hull geometry change on resistance or buoyancy. Inclusion of internal properties 
(hull subdivision, weight distributions and tank placements) allow a designer to perform major arrangements and 
assess those choices for stability. Obviously, the advantage of the integrated env ironment is fewer design errors, 
reduced commmiication overhead, and greater productiv itv*. 

Based on the DDG-51 program data, some integrated design and analysis was available in concept design. 
However, this was less apparent in preliminarv' design and beyond. As such, the current model considers the efforts 
of hull engineering as separate disciplines. Future v anations of the design process model, may reflect the integrated 
environment through a merging of design disciplines. However, design tasking will not entirely merge as detailed 
design tasks (such as structimxl engineering and arrangements) are still specialized disciplines requiring separate 



J. Evans, “Basic Design Concepts”, Naval Engineers Journal , November 1959. 
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design actions. For instance, Newport News Shipbuilding uses an integrated software environment (VIVID s\stem 
using a 3D product model) in detailed design. Altliough the system provides a common interface and model 
information is fully accessible to all designers, the design team still requires separate structural designers, weight 
engineers, arrangement speciahsts, etc... to perform specific design tasks, and discuss design and analysis results in 
a team enviromnent. 

The task and productivity hull design levels for the baseline case (DDG-51 program) arc provided in Chapter 
8.5. The justification for the DSM is provided below . 

4.6.1 Hull Geometry 

Hull geometry is the cornerstone of hull engineering. Hull geometry’, or the ship’s lines, must meet precise 
and unambiguous” design constraints... and will “consist of orthographic projections of the intersections of the hull 
form vvitli tlirce mutually perpendicular sets of planes.”^ As simple as tliat may sound, the process is quite 
complex. The selection of specific hull parameters (length, beam, draft), hull coefficients (prismatic, waterplane, 
block, midship section), and fairing of hull lines requires iteration and trade-off. To facilitate early design, 
paranietrics and established design lanes are often utilized to estimate hull size and shape. These parameters 
tvpically require estimates of weights, w eight distribution and desired hull speed as inputs. The parameters are then 
iterated for convergence against requirements. More adv anced hull geometrv’ algoritlims, such as the HULGEN 
program in ASSET, combme parametric selections for baseline sizing with a parent hull design to fair intermediate 
station values to tlie hull parameters and coefficients. Tliese methods prov ide a consistent basis for concept trade- 
off and perturbations. However, critics point out that use of design lanes constrain innov ation. 

At the preliminary design stage, hull geometry’ uses 3-D graphical modeling and scale model construction. 

As with performance assessment (Chapter 4.5.4), hull geometrv' design matured greatly with the introduction of 
modeling programs like Hull Form Definition System (HFDS) with its integrated generation and manipulation 
modules (FastShip, FASTGEN, and IADS.)^“^ Tliese programs provide increased ability to both generate and 
optimize hull foniis relative to resistance, particularly for monohull designs. Other hull performance analysis, like 
seakeeping and stability’, is also facilitated by common, digital, hull geometry’ definitions. Unusual hullforms, such 
as multi-hull designs or the wave pieremg bow, must still be physically modeled and tested. Such testing not only 
supports the current design, but provides calibrating data for fiiture computer modeling. 

In addition to the basic hull geometry, other hull characteristics may be selected and modeled to enhance 
performance. For instance, bow (like the bulbous bow) and stem configurations are optimized to reduce resistance 
while maintaining adequate seakeeping charactenstics. 



Scott Ripley, Interview at Newport News Shipbuilding, Newport, VA, August 29, 1997. 

Normal Hamlin, “Ship Geometry’”, Principles of Naval Architecture, Society of Naval Architects and Marine 
Engineers, Jersey City’, NJ, 1988, Volume I page I. 

Gale and Scott, '*Earlv Stage Ship Design Seminar”, Societv’ of Naval Architects and Marine Engineers, Jersey 
City’, NJ, 1988. 

Whatmore and Wintersteen, A Review of Extant Design Tool Capabilities to Identity’ Common Design Tools for 
Future Collaboration, Naval Surface Warfare Center Carderock Division, Bethesda, MD, 1997, page 20. 
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Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Principle Dimensions 


1 


1 


1 


1 


1 


1 


1 


Parent Ship Properties 


1 


1 


1 


1 


1 


1 


1 


Hullform 


1 


1 


1 


1 


1 


1 


1 


Lines Drawings 


1 


1 


1 


1 


1 


1 


1 


3-D Model 




1 


1 


1 


1 


1 


1 


Curves of Form 




1 


1 


1 


1 


1 


1 


Hull Design Specifications Input 




1 


1 


1 


1 


1 


1 


Hull Design History Input 




1 


1 


1 


1 


1 


1 


Model Test Plan and Model Construction Plan 




1 


1 


1 


1 


1 


1 


Stern Reconfiguration 






1 


1 


1 


1 


1 



Table 23 Hull Geometn’ Tasks 

Table 23 shows the progression of hull geometr\^ tasks in the design process. As discussed above, initial 
tasks are parametrically generated The inputs includes weights, mechanical and combat s>*stems, and requirements 
(speed resistance, stabihty). Hull geometry^ represents a field of pure design. In other words, hull geometiy^ is the 
definition of ship characteristics without explicit performance analysis (hull performance analysis is addressed as 
separate disciplines.) 

Generally, all disciplines may be categorized as pure design, pure analysis (a discipline that describes tlie 
perfonnance of a design characteristic, but does not necessanly have the capability or authority to modity' that 
characteristic) or some combination of design and analysis. As a pure design discipline, hull geometry^ must provide 
hull engineering input to analysis disciplines wliich include: weight engineering, hydrodvmamics, structures, marine 
engineenng, cost and programmatics. 

4.6.2 Weight Engineering 

Weight engineering is a discipline of assessment and design. Weight engineering estimates distribute and 
account for mass distributions in the ship. In early design iterations, these distributions may be purely empirical 
with only a few mass locations (such as engines or combat systems) explicitly known. As the design matures, 
weight engineering relies increasingly on known arrangements, structural specifications, machinery integration and 
combat s> stems integration for specific placement of weiglits and their locations. These tasks are considered weiglit 
accounting. Anotlier task is hydrostatic definition of the hull. Using the defined hull geometiy^ and internal 
subdivision (arrangements), weight engineers generate bonjean curv’es. floodable lengtii curves, and other 
hydrostatic displacement tools. Given mass-moment and hydrostatic properties, static stability (stability for specific 
angles of heel) is assessed. The analysis w ill include both intact and damaged conditions. 
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Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Deck Height Reduction Study 


1 


1 


1 


1 


1 


1 


1 


Machinery Space Tightness Study 


1 


1 


1 


1 


1 


1 


1 


Tank Arrangements 


1 


1 


1 


1 


1 


1 


1 


Bonjean Curves 


1 


1 


1 


1 


1 


1 


1 


Stability Assessment 


1 


1 


1 


1 


1 


1 


1 


Weight & Mass Properties Analysis 


1 


1 


1 


1 


1 


1 


1 


'‘ability Specifiation Input 




1 


1 


1 


1 


1 


1 


Stai;;'.'ty Design History Input 




1 


1 


1 


1 


1 


1 


Weight (3-. 5-Digit & Contract Weights/Centersj Estimates 




1 


1 


1 


1 


1 


1 


Contract Design Weight Estimates 




1 


1 


1 


1 


1 


1 


Weight Control Program Reports 




1 


1 


1 


1 


1 


1 


Weight Specifications Input 




1 


1 


1 


1 


1 


1 


Weight Design History Inputs 




1 


1 


1 


1 


1 


1 


Construction Margin Report 




1 


1 


1 


1 


1 


1 


Weight Database (to initialize design) 




1 


1 


1 


1 


1 


1 


Margin Allocations 




1 


1 


1 


1 


1 


1 


Floadable Length 




1 


1 


1 


1 


1 


1 


Intact and Damaged Stability Analysis 




1 


1 


1 


1 


1 


1 


Volume and Displacement 




1 


1 


1 


1 


1 


1 


Master Weight Files and Data Sheets 






1 


1 


1 


1 


1 



Table 24 Weight Engineering Tasks 

Table 24 shows the progression of weight engineering tasks. These tasks are dominated b>' accounting and 
analysis. As such, weight engineering requires input from all design specific disciplines as well as requirements. 
Output goes to hydrodynamics (seakeeping requires rigliting moment data) and provides first order analysis to 
structures (for weight distribution ciuves), arrangements, and systems selections (i.e. weight critical loads may need 
to be mov ed or reduced.) 

4.6.3 Hydrodynamics-Resistance and Powering 

Resistance and powering anal>^es the link between requirements, hull geometry , appendage design, and 
propulsion plant selection. For early design, resistance is empirically based (Taylor Standard Series resistance.) 
Later design analysis includes model testing and numerical methods (computational fluid dynamics (CFD) models.) 



As discussed previously (see Chapter 4.6.2), the analysis methods for hydrodynamics are increasingly integrated 
with design tools to provide improv ed design iteration. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Powering/Resistance Charactistencs 


1 


1 


1 


1 


1 


1 


1 


Speed-Power Requirements and Report 


1 


1 


1 


1 


1 


1 


1 



Table 25 Hydrodynamics-Resistance and Powering Tasks 
Table 25 shows the two primary^ resistance analysis task tvpes (resistance determination and report of results 
relative to requirements.) Input requirements include all factors effecting resistance and speed calculations 
(hullform, appendages, powering.) For the current naval ship design process model, output includes hull geometiy*. 
requirements, appendage design and propulsion plant design. Future model considerations merge many of the 
design and analysis tasks in an integrated design environment. 

4/3.4 Hydrodynamics-Seakeeping 

Seakeeping is tlie measure of mission performance of the hullform, and, subsequently, all ship sv stems. 
which considers ship motion in the operational environment. Like resistance, it represents a pure analysis discipline 



85 



that is being increasingly integrated in a design environment. For instance, the current generation of HFDS provides 
both geometiy^ manipulation and seakeeping analysis with programs including: Ship’s Motion Program (SMP), 

S WMP and SWISP modules for SWATH hullforms, and Seakeeping Evaluation Program (SEP). In past programs, 
seakeeping was rarely addressed in early design. Tliis fact is apparent in the tasking from Table 26. However, 
seakeeping is increasingly important in early design today due to demanding mission requirements. These 
requirements include a greater range of operating environments and greater seakeeping demands to support fliglit 
operations, crew and payload performance. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Seaway Seakeeping Performance Assessment 


1 


1 


1 


1 


1 


1 


1 


Seakeeping Report 






1 


1 


1 


1 


1 



Table 26 Hydrodynamics-Seakeeping Tasks 

Seakeeping requires inputs from requirements, hullform, appendages and weiglit properties, as well as 
auxiliar>' systems (active stabilization). (Outputs from seakeeping go to programmatics, hull geometry and 
appendage sizing. A very^ important output is provided to structural analysis. Structural analysis uses dynamic sea 
loads to de\ elop the structural design for tlie hull. 

4.6.5 Hydrodynamics-Maneuvering, Control and Appendages 

Maneuvering, control and appendages are the remaining sy'stem considerations relating to the hull -w ater 
interface. “(M^euvering) includes starting, steering a steady course, turning, slowing, stopping, backing. . . 

Tliese tasks include the design and assessment of appendages including rudders, propellers, and passive stabilizers. 
Specific tasks are shown in Table 27 below. These tasks are determined in a manner similar to all previous design 



disciplines. Additionally, tlie tasks are supplemented by the an excellent summaiy^ and description of the component 
tasks found in Table 22 of Principles of Naval Architecture . 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Propeller Design Report and Diagrams 


1 


1 


1 


1 


1 


1 


1 


Controllability Assessment 


1 


1 


1 


1 


1 


1 


1 


Propeller Trade-Off Study 




1 


1 


1 


1 


1 


1 


Propeller Specification Input 




1 


1 


1 


1 


1 


1 


Propeller Design History input 




1 


1 


1 


1 


1 


1 


Control and Manuevermg System Design 




1 


1 


1 


1 


1 


1 


Hull Equipment & Appendage Design 




1 


1 


1 


1 


1 


1 


Maneuvering and Propeller Soecificatioh Inputs 




1 


1 


1 


1 


1 


1 


Maneuvering and Propeller Design History Inputs 




1 


1 


1 


1 


1 


1 


Hydro Performance Assessment 




1 


1 


1 


1 


1 


1 


Steering Gear 




1 


1 


1 


1 


1 


1 



Table 27 Hydrodynamics-Maneuvering, Control and Appendages Tasks 
Data interfaces for maneuvering and control include inputs from requirements, hullfonn, weight distributions 
(for turning moments), propulsion plant configuration (for propeller sizing) and aaxiliarv’ systems (for active control 
systems.) Output goes to programmatics and performance, producibility (for integration of appendages), hull 

Crane, Eda. Landsburg, ‘‘Controllability ", Principles of Naval Architecture . Society^ of Naval Architects and 
Marine Engineers, Jersey City, NJ, 1988, cliapter IX. 

Ibid. 
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gcometn^ and weights (for design to performance iterations) and mechanical s> stems (for adequate sizing of 
maneuvering auxiliaries.) 

Note that propeller design is included with maneuvering design. It is equally acceptable to include those 
tasks under propulsion engineering. 

4.6.6 Structural Engineering 

Structural engineering requires the design of hull and deckhouse structure to resist static and dviiamic loads 
on the hull. Additionally, structural engineering provides for support and isolation of instal’od equipment by means 
of foundations and force absorbers. Structural engineering requires inputs from mission requirements and assessed 
performance, hull configuration and loading, and installed equipment and systems. Structural engineering is a 
combined design and analysis discipline. Early structural design uses parametric weight distributions and historical 
wave characteristics, generates anticipated longitudinal bending stresses from these characteristics, and iterates tliis 
process to define a midship section. As the design matures, sections are generated for multiple locations in the hull. 
In areas of higher risk (such as dv namic loading of radars on masts), finite element analysis (FEA) may be used. 
Later in the process, critical spaces (machiner>^ box, magazines, etc) and e\ entually tlie entire ship are modeled in 
FEA. During detailed design, structural engineering is a prime focus for hull design as the complete hull geometry 
is translated into structural components and details. Specific implementation of structural design is found in 
Hughes^ and Paulling^^^. Structural output is used by programmatics and performance assessment, hull geometiy 



and weights, and arrangements. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Define Midship Section Structure 


1 


1 


1 


1 


1 


1 


1 


Longitudinal Strength Assessment 


1 


1 


1 


1 


1 


1 


1 


Payload Structural Assessment 


1 


1 


1 


1 


1 


1 


1 


Shipyard Producibility Practices 


1 


1 


1 


1 


1 


1 


1 


Frame Spacing 


1 


1 


1 


1 


1 


1 


1 


Structural Assessment 


1 


1 


1 


1 


1 


1 


1 


Noise & Vibration Analysis 


1 


1 


1 


1 


1 


1 


1 


Design Criteria 




1 


1 


1 


1 


1 


1 


Structural Specfication Input 




1 


1 


1 


1 


1 


1 


Calculation Report 




1 


1 


1 


1 


1 


1 


Structural Arrangement 




1 


1 


1 


1 


1 


1 


Deck Structural Drawings 




1 


1 


1 


1 


1 


1 


Structural (Scantling) Drawings 




1 


1 


1 


1 


1 


1 


Superstructure/Deckhouse Structural Drawings 




1 


1 


1 


1 


1 


1 


Foundation Design & Weight Effective Foundations 




1 


1 


1 


1 


1 


1 


Structural Design History Input 






1 


1 


1 


1 


1 


Bulkhead Structural Drawings 






1 


1 


1 


1 


1 


PSDM 






1 


1 


1 


1 


1 



Table 28 Structural Engineering Tasks 

Table 28 shows the progression of structural design tasks. Note from Chapter 8.5 tliat over the course of the 
process structural productivity must increase dramatically (by a factor of 200%) to accommodate the substantial 
increase in structural design effort required for detailed design. 



Hughes, Ship Structural Design . Society of Na\ al Architects and Marine Engineers, Jersey Cit\\ NJ, 1988. 
Paulling, “Strength of Ships”, Principles of Naval Architecture . Society of Naval Architects and Manne 
Engineers, Jersey City, NJ, 1988, chapter IV. 
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4.6.7 Space and Arrangements 



Space and arrangements are the means by which the hull volume is allocated and optimized In pre-detailed 
design, general arrangements identify the location, physical boundaries and function of each space in the ship. 

These locations are utilized for weight engineering, survivabilify' assessment (redundancy, separation and 
permeabilify ). and manning accommodations. In detailed design, the concern is the development of arrangements of 
equipment within each space with provision for required access to eveiy' component on the ship. Specifically, the 
location of equipment must be selected to satisfy' individual component performance (location of radar transmitters 
to minimize wave guide runs), component s\'stem performance (redundant fire pumps separated for survivability) 
and total svstem performance (zonal distribution and Collective Protective System (CPS) location.) 

The outputs from arrangements are a significant input to programmatics and specifications. In particular, 
arrangement drawings and Master Equipment Lists (MEL) are an important component of configuration baseline 
designs that complete a design iteration As a design clement, arrangements are utilized by performance assessment 
and weights for analysis. Additionally, hull arrangements must converge with macliinerv' and combat sv stems 
arrangements. (Note that machineiy^ systems and combat s> stems integration include specific arrangement tasks due 
to the unique requu*ements of those disciplines.) 

Table 29 shows the progression of space and arrangements design tasks. Note that like most other hull 
engineering disciplines, initial tasks are based on parametric or empirical design, and later phases rely on physical 



placement of components. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Arrangements 


1 


1 


1 


1 


1 


1 


1 


Compartment & Access {C&A) List & Oufit Drawings 


1 


1 


1 


1 


1 


1 


1 


Area Requirements 


1 


1 


1 


1 


1 


1 


1 


Volume Requirments 


1 


1 


1 


1 


1 


1 


1 


HVAC, CPS and Zonal System Arrangements 


1 


1 


1 


1 


1 


1 


1 


Specification Control Drawings (SCD) and Specification Inputs 




1 


1 


1 


1 


1 


1 


2D/3D CAD Model Extraction 




1 


1 


1 


1 


1 


1 


Outfitting T rade-Off Studies 




1 


1 


1 


1 


1 


1 


Office Space Arrangement Drawigns 




1 


1 


1 


1 


1 


1 


Medical Arrangements Drawings 




1 


1 


1 


1 


1 


1 


Outfitting Specifications Inputs 




1 


1 


1 


1 


1 


1 


Outfitting Design History Inputs 




1 


1 


1 


1 


1 


1 


General Arrangement Drawings 




1 


1 


1 


1 


1 


1 


Habitability Drawings 




1 


1 


1 


1 


1 


1 


CPS/Zonal Distribution System Drawings 




1 


1 


1 


1 


1 


1 


Design History Input 




1 


1 


1 


1 


1 


1 


Functioinai Drawings - Series "K" 








1 


1 


1 


1 


Fabrication Drawings - Series "F" 












1 


1 


Installation Drawings - Series "1" 












1 


1 


Closure List 












1 


1 



Table 29 Space and Arrangements Tasks 

4.7 Machinery Systems Engineering 

Machineiy' systems engineering, or marine engineering, is the selection and integration of propulsion, 
electrical and support s>'stems. Historically, the boundarv' between machincrv' engineering and hull engineering is 
indistinct. For instance, propeller design is equally important to both disciplines Likewise, the hull form 
determines the propulsion power required to achiev c sustained speed levels and the selected propulsion plant 
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determines the necessary hull form to support the plant. These interdependencies are reflected in the DSM for na\ al 
ship design. Detailed examples of machinery tasks and interdependencies can be found in Harrington^ 

Machinery engineering is an interdisciplinary task set that draws on engineering disciplines ranging from 
mechanical to electrical to chemical to civil engineering. Specific components of machinery design include: 

• Propulsion and transmission s>^stems 

• Electrical generation and distribution 

• Environmental, fluid and support auxiliar>^ systems 

• Non-combat related auxiliary systems (deck, handling and aviation machinery) 

In addition to component selection and design, the machinery plant must be integrated into the total ship and 
consider the total impact of machinery systems on fuel capacity, stack length, and net component accounting 
(weight, space and specification). Machinery system discipline productivity and task levels are provided in Chapter 
8.5. 

4.7.1 Machinery Systems Design and Integration 

Macliinery system design is the integration of subordinate mechanical systems in the ship design. For early 
design phases, this integration provides determination of total fuel requirements (endurance fuel and electrical 
generation fuel) and maclimery arrangements. Preliminary' machineiy' stack length and plant sizing is parametrically 
linked to ship dimensions (length, beam, hull depth). As such, ship geometry is a key input to system design. 
Additional inputs include requirements, perfonnance assessment, weights and arrangements (hull and topside), hull 
perfonnance (resistance), and cost. In later design stages, machinery systems become better defined with specific 
components selected via designation in the Master Equipment List (MEL) and other parts lists. System diagrams 
(cableways, piping, etc) are developed and refined in coordination with general arrangements. Machinery control 
systems are developed for the selected mechanical sy stems. 

The output from systems design must match general and topside arrangements, weight accounts, performance 
estimates and programmatic requirements. Table 30 lists the progression of system tasks. Note that throughout 
mechanical sy stems design, there is little mention of mechanical sy stems development. Rather, it is assumed that 
the chosen sy stems are mature and available w hen required for design mtegration. Future iterations of the design 
model may consider specific development schedules for high risk technologies (such as RACER for DDG-5 1 or 
Integrated Propulsion System (IPS) for DD-21) and represent those dynamics endogenously. 
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Roy Harrington. Marine Engineering , Society of Naval Architects and Marine Engineers, Jersey City, NJ, 1992. 

89 



I 

\ 

i 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Fuel Requirements 


1 


1 


1 


1 


1 


1 


1 


Ship System Development 


1 


1 


1 


1 


1 


1 


1 


Machinery Arrangement 


1 


1 


1 


1 


1 


1 


1 


Master Equipment List (MEL) 




1 


1 


1 


1 


1 


1 


SSES & LBEF & SSEB Support 




f 


1 


1 


1 


1 


1 


Machinery Developments Studies 




1 


1 


1 


1 


1 


1 


Machinery Controls 




1 


1 


1 


1 


1 


1 


Machinery Control Arrangements 




1 


1 


1 


1 


1 


1 


Outfit and Furshining 






1 


1 


1 


1 


1 


Material Design Standards 








1 


1 


1 


1 


System Diagrams with associated parts list 








1 


1 


1 


1 


Interference Checking 










1 


1 


1 



Table 30 Machinery Systems Design and Integration 

4.7.2 Propulsion Systems 

Propulsion s\ siems engineering is the selection and design of the components of the propulsion train. As 
discussed previously, these efforts do not require the specific development of a propulsion engine (such as a specific 
gas turbine or diesel engine). Rather, they provide for the selection of engines, determination of required ship 
support for tlie engines and development of power train elements for transmission of power. It is possible that 
selected engine s> stems may not be mature during the initial design phases. This is particularly true during the 
development of nuclear power sv'stems or new technologies (such as IPS.) For the purposes of the current model, 
these issues are ignored. However, such issues can have a significant c> cle time impact on design. Aside from 
pnme mo\ ers, many unique components such as reduction gear, shafting and clutches, may be specifically designed 
within the context of the naval engineering process. Table 3 1 describes many of the specific power sv stem decisions 
that must be made during this tasking. 



Number of propulsors/shafts 


Direction of shaft rotation 


Number of engine rooms 


Number/Tvpc of prime movers 


Gear T>pe/Location 


Exhaust energv' usage 


Power transmission method 


Fuel T\pe 


Pow er plant location/geometrv' 


Power plant mounting 


K factors 


Gear Configurations 


Regeneration 


Thrust reversing method 


Control t\pe 


Inlet type 


Exhaust t>pe 


Deicing metliod 


Power plant locations 


Airborne noise control 


Vibration control 



Table 31 Key Propulsion System Trade-Off Parameters'^' 



In concept design, propulsion plant engineering is tvpically restricted to selection of a powering concept and 
determination of adequacy of the concept to meet performance requirements. As such, inputs must include 
perfonnance, hull resistance, propulsor concepts, hull arrangements and propulsion support svstems. Note that 
propulsor design is included with maneuvering and control. It would be equally acceptable to include propulsor 
design with the propulsion train instead. 



M\Ton Ricketts, Manual for Naval Surface Ship Design Technical Practices , Naval Sea Systems Command, 
Washington DC, 1 980. 
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As machinery space, weight requirements, and fuel needs are generated the output is iterated against 
performance, maintenance and mamiing concepts, weiglits and hull arrangements, support s\stems and cost. Later 
iterations of the propulsion plant further refines these outputs and examines transmission concepts, \ibration. stack 
design, and fluid s> stems. Final design stages require specific arrangements of propulsion components and support 
systems and management of production preparations (parts and components ordering.) The complete progression of 



propulsion sy stem tasking is found in Table 32. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 1 Zonal 


Production 


Mam Propulsion Concept 


1 


1 


1 


1 


1 


1 


1 


Main Engine Selection 


1 


1 


1 


1 


1 


1 


1 


Propulsion System Trade-Off Study 




1 


1 


1 


1 


1 


1 


Fluid System Diagrams 




1 


1 


1 


1 


1 


1 


Endurance Fuel Requirements 




1 


1 


1 


1 


1 


1 


Propulsion System Design Report Input 




1 


1 


1 


1 


1 


1 


Propulsion System Specification Input 




1 


1 


1 


1 


1 


1 


Shafting Drawing 




1 


1 


1 


1 


1 


1 


Shafting Vibration Analysis 




1 


1 


1 


1 


1 


1 


Propulsion System Design History Input 






1 


1 


1 


1 


1 


Stack Gas Flow 






1 


1 


1 


1 


1 



Table 32 Propulsion Systems Tasks 



4.7.3 Electrical Systems 

Electrical systems design follows a similar progression as propulsion plant design. During early design 
stages, an electrical sy stem concept is developed to accommodate performance requirements, support systems and 
combat systems. Electncal requirements are initially sized based on manpower levels, hull parameters and known 
power requirements for selected shipboard systems. Later design stages examine electrical load demand and 
distribution. Management and accounting of electrical capacity' and demand becomes increasingly important later in 
design as sy stem growth naturally occurs. 

Electrical system growth is substantial over time. The first naval \ esscl equipped with electrical pow er (the 
cruiser USS TRENTON in 1883) had 13.2 kW of power capacity. In contrast the DD 963 destroyer (1970's) has 
6000 kW capacity' and tlie DDG-51 (1980's) has 7500 kW. This growth in electric requirements is attributed to the 
following technological developments^ 

• Weapons dc^'elopment including ammunition handling and electronic warfare sy stems 

• Electronic command, control, and navigation sy stems with higli powered radar, sonar, and electronic data 
processing equipment 

• Habitability improvements including electric heating, air conditioning, illumination, and refrigerated storage 

• Increased use of electric and electrohydraulic auxiliary systems 

These trends require some increases in electrical design effort. However, the greatest trend impacting effort is the 
inclusion of Integrated Power Systems (IPS.) With the design of an '^all-electric'’ ship, this category' of design could 
experience significant growth. 

For the current model, DDG-5 1 efforts are modeled with the task progression shown in Table 33. 



Ibid., page 10-8. 
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Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Electric Distribution Design 


1 


1 


1 


1 


1 


1 


1 


Electric Plant Concept 


1 


1 


1 


1 


1 


1 


1 


Electrical Line Diagram 




1 


1 


1 


1 


1 


1 


Lighting Analysis 




1 


1 


1 


1 


1 


1 


Electrical System Specification Input 




1 


1 


1 


1 


1 


1 


Electrical System Trade-Off Study 




1 


1 


1 


1 


1 


1 


Electrical Load Analysis 




1 


1 


1 


1 


1 


1 


Electrical System Design History input 






1 


1 


1 


1 


1 



Table 33 Electrical Systems Tasks 

4.7.4 Auxiliary and Support Systems 

Aaxiliaty systems design includes those system required to support ship s>'stems. Specifically, SWBS group 
500 items dominate this category of design. Auxiliary’ systems are selected based on inputs from requirements and 
performance, manning, hull geometry (utilized for concept level sizing), control sy stems, available weight and 
space, propulsion and electrical systems, and combat systems. The selected systems provide capabilities for: 

• Damage Control . . .ventilation, dewatering, sensing. CPS 

• Environmental Control . . . heating, v entilatioa air conditioning, refrigeration 

• Fluid Management ... sea water supply, fresh water generation and distribution, air/gas supply 

• Pollution Control. . .oily waste systems, sewage treatment, solid waste disposal, chemical/toxic waste 
disposal 

As a closed loop design process, output selections are provided to input categories and costing for comparison and 
iteration. With the introduction of increased compuUng capacity^ aboard modem warships, this category' may grow 



to provide adequate environmental conditioning. For the baseline case, tasking is established per Table 34. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Distributive System and Auxiliaries Design 


1 


1 


1 


1 


1 


1 


1 


Fluid System Trade-Off Studies 




1 


1 


1 


1 


1 


1 


Fluid System Arrangement Diagrams 




1 


1 


1 


1 


1 


1 


Fluid System Design Hi^orv Input 




1 


1 


1 


1 


1 


1 


Fluid System Specifications Input 




1 


1 


1 


1 


1 


1 


HVAC T rade-Off Studies 




1 


1 


1 


1 


1 


1 


HVAC Diagrams and Arrangement Drawings 




1 


1 


1 


1 


1 


1 


Fart Room Arrnagements 




1 


1 


1 


1 


1 


1 


HVAC Design History Input 




1 


1 


1 


1 


1 


1 


HVAC System Report 




1 


1 


1 


1 


1 


1 


HVAC Specification Input 




1 


1 


1 


1 


1 


1 


HVAC System Requirements and Criteria 






1 


1 


1 


1 


1 


Steering Systems 






1 


1 


1 


1 


1 



Table 34 Auxiliary and Support Systems Tasks 

4.7.5 Deck, Handling and Aviation Support Systems 

Tile remaining systems are those components assigned to SWBS groups 570, 580 and 590. Specifically, 
these systems are required to support conventional ship operations (like mooring, anchoring, towing, etc), underway 
replenishment operations (UNREP) and aviation operations. These sy stems are less dependent on input then 
previous mechanical sy'stems. Specifically, input is required from performance and requirements, weight and space 
allocations and electrical and support system budgets. Tlie design output is returned to the input disciplines and 
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cost, manning and maintenance. The progression of task elements is prov ided in Table 35. For future design 



models, these tasks will input to topside design because of their importance of reducing ship signatures. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Deck/UNREP Systems 


1 


1 


1 


1 


1 


1 


1 


Deck System T rade-6ff Studies 




1 


1 


1 


1 


1 


1 


Anchor Mooring & Towmg Drawings 




1 


1 


1 


1 


1 


1 


Deck Systems Design History inout 




1 


1 


1 


1 


1 


1 


Deck Systems Specification Input 




1 


1 


1 


1 


1 


1 


Aircraft Support System 




1 


1 


1 


1 


1 


1 


Boat Handling and Stowage Arrangements and Drawings 




1 


1 


1 


1 


1 


1 



Table 35 Deck, Handling and Aviation Support Systems Tasks 

4.8 Mission Systems Engineering 

Mission s>stems engmeenng, also known as combat sv stems engineering, is the selection and integration of 
those combat payloads necessary to meet the mission requirements of the surface combatant. Tire selected sy'stems 
must be fully integrated into tlie arrangements of tlie combatant. Recall the combat sy stems trends discussed in 
Chapter 1.1.3 and Figure 12. Older combat sy stems (gun sy stems and visual guidance) were weight critical, dense, 
and placed low in the hull. The resulting ship had large displacement, but smaller beam for the desired stability 
requirements. The combat system provided a reaction time suitable for the threats of that time. As threat 
capabilities advanced, combat sy stems matured vvitli the transition from guns to missiles and visual to radar 
guidance Consequently, the ship integration issues changed. Modem warships must accommodate volume and 
height critical systems to achiev e necessary^ performance. The result was initially lower displacement in ships like 
the DD-963 with less dense, moderately high systems. As response time and multi-mission performance demanded 
increased sensor height and greater payload v olume, displacement and beam growth was necessary^ to provide 
adequate stability for highly placed radar sy^stems. 

Note that combat sy stems engmeering in this context is not the design of combat sy stems themselv es. The 
fields of combat systems design (detect to engage chains) and testing (probability of detect and kill, reliability , etc) 
represent product dev elopment processes unto themselves. Altliough these sy stems are becoming increasing 
integrated into the ship development process (such as the Aegis Weapon System and CG-47), removing weapon 
sy stems development from the boundaries of tlie model is necessary^ to allow examination of naval ship design. 
Future models may endogenously include major weapon systems development. However, tliese sy stems should 
only be included if tlie weapon sy stems dev elopment schedule are shown to dy namically influence tlie ship design 
process. 

Baseline productivity and task levels for the DDG-5 1 program combat sy stems integration (independent of 
combat systems development) are provided in Chapter 8.5. 

4.8.1 Mission Systems Selection, Design and Integration 

Mission sy stems include those payloads required for tlie combatant to satisfy specific warfare requirements of 
the ORD Tliese sy stems can include commumcatioiis (both internal and external), sensors, weapons and control. It 
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does not include the development process of those systems, but rather assumes systems are available and must be 
integrated with the ship design. Note that there has been tremendous criticism over the years concerning the 
apparent disconnect between the ship design communit}^ and weapon s} stems development community. 

Specifically, lack of coordmation between the two communities has lead to tremendous schedule fluctuations. 
Consider Figure 33. The figure shows the months required to launch each vessel in the class for the CG-47 Aegis 
Cruiser. Note that the class experienced 4 major combat system baseline changes over the course of the program. 
This can be correlated to the four oscillations in delivery schedule. This trend dominates actual hours of effort 
which reflect the expected learning curv e. Thus, schedule delays from late GFE/GFI/GFM effectively negate the 
benefits of production efficiencies. This trend is changing in current programs like DD-2 1 and should be considered 
in future model designs. 

Input requirements for mission sv stems design include performance and requirements, weight and space 
budgets, support sv stem capacity and topside arrangement issues. Output is iterated with the same disciplines as 
well as structural design and cost, The complete progression of design tasks is shown in Table 36. 




Figure 33 CG-47 Class Deliverv Schedules and Production Efforts‘^“* 



Tibbitts and Keane, “Naval Slup Design in the 2T^ Century"’, Society of Naval Architects and Marine Engineers. 
Jersey City, NJ, 1993. 

Mike Jeffers, Interview at Naval Surface Warfare Center Carderock Division, Bethesda, MD. November 12, 
1997. 
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Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Combat System Integration Management 


1 


1 


1 


t 


1 


t 


1 


IC/Navtgation Integrabon and Diagrams 


1 


1 


1 


1 


1 


t 


1 


EytenorComms{SPAWAR-NAVELEX) System & Antenna Integration 


1 


1 


1 


1 


1 


1 


1 


Shipboard Data Multiplex System (SDMS) 




1 


1 


1 


1 


t 


1 


Combat Systems Design Support. Testing, IVCS & ISMS 




1 


1 


1 


1 


1 


1 


Command and Control Space Arrangements 




1 


1 


1 


1 


1 


1 


Mission Systems Design History Input 




1 


1 


1 


1 


1 


1 


Mission Systems Specification Input 




1 


1 


1 


1 


1 


1 


Armament and Weapon Systems Integration 




1 


1 


1 


1 


1 


1 


1C Matrix 






1 


1 


1 


1 


1 



Table 36 Mission Systems Selection, Design and Integration Tasks 

4.8.2 Topside Design and Integration 

With the introduction of modem weapon s> stems (missiles, communications, and radars) has come increased 
need to manage topside design. Specifically, modem combat s\ stems generate unique integration problems due to 
azimuthal coverage requirements, electromagnetic interference (EMI), signature reductions including radar cross 
section (RCS) and Infrared (IR), and aperture heiglit requirements. These needs require detailed accounting and 
modeling of sy stem interactions and allocation of valuable topside real estate. At the concept level, integration is 
t}pically linuted to basic arrangement diagrams. The requirements for inputs include mission s> stems selected, 
distance and capacity of supporting s> stems, arrangements of non-combat system topside elements (deck, handling 
and aviation s> stems), and perfomiance requirements. Of particular concern are the mass moment and subsequent 
stability of the ship. As topside s\ stems demand increasing heights and weights, the impact on hydrostatic 
performance is significant. As discussed previously, these impacts are proving e\ olutionaiy^ in combatant ship 
design. 

In later stages of topside design, specific analysis of EMI impacts, coverage, source-victim effects, and 
combat system performance must be addressed to optimize topside arrangements. Like hull engineering (HFDS), 
the demands of technology coupled w ith tlie current trend to integrate design and analysis has resulted in the 
creation of softw are suites for topside engineering. Systems such as LEAPS and Electromagnetic Engineering 
(EMENG) are pro\ iding topside engineers with the ability to anahze greater combat s> stems detail much earlier in 
the design process. Such efforts are necessan^ if modem w arships are to meet current requirement demands for 
passive and active defense. Later variations of the design process model may be modified to reflect the increased 
concept design effort necessary^ for programs like the DD-21. The baseline tasking progression is shown in Table 
37. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Topside and Combat Systems Integraoon 


1 


1 


1 


1 


1 


1 


1 


Topside & Combat Systems Arrangements 


1 


1 


1 


1 


1 


1 


1 


topside Arrangement Drawings 




1 


1 


1 


1 


1 


1 


EMI Analysis 




1 


1 


1 


1 


t 


1 


Arcs of Fire & BAM Analysis 




1 


1 


1 


1 


1 


1 



Table 37 Topside Design and Integration Tasks 

Output from topside engineering is iterated with mission sy stems selection, support s>'stems. arrangements, 
w eight, perfomiance, maintenance and manning, and progranunatics. 
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4.9 Cost Engineering 



A final component of the total s> stems engineering process, along w ith performance assessment and 
schedule, is cost. In this context, cost represents all aspects of total ownersliip cost (TOC) for the developing 
system. In the context of the naval ship design process, cost engineering represents that component of ship design 
by w hich the acquisition and life cycle cost of the developing design is assessed against program cost constraints. 

As such, it does not include the expenditures of funds for R&D or current spending on the design process (those 
current costs are modeled explicitly, see Chapter 5.5). Cost engineering addresses the specific cost d\namics 
discussed pre\iously in Chapters 1.1.3 and 2.3. These beha\iors demonstrate that cost is and will continue to be the 
primaiy' driver in naval ship design and acquisition. DDG-51 cost constraints explicitly operated as a closed loop 
feedback control process... indicative of a d\namic control process. Exceeding cost estimates resulted in 
significant design effort and design change (see Figure 16.) Tliis trend is severely criticized in liglit of questionable 
cost estimate accuracy. The result is increased demand for robust costing methods such as Product-Oriented Design 
and Construction (PODAC) cost models and access to costing models such as ACEIT at tlie engineering level. 

These issues are beyond the scope of this w ork. How ever, the impacts of these methodologies provide more tasks m 
earh' design off-set by decreased iterations generated from cost. The result is a relatively constant productivity rate 
for costing and decreased feedback late in the design process (after concept design.) 

Chapter 8.5 contains productivity' and tasking baseline data for the DDG-51 program. Specific types of cost 
estimates and their relationships to tlie design process are provided below . 

4.9.1 Cost Estimates and Analysis 

Cost estimates and analysis are the aggregates of all engineering cost studies for the naval ship design 
process. These estimates represent specific types of cost estimates required by DoD doctrine at each milestone and 
consequentially, each design phase. Note that design process budgeting considers a separate process within the 
naval sliip design model. Budgeting for the design is accomplished by the Planning, Programming, and Budgeting 
System (PPBS) and is explicitly modeled (see Chapter 5.5). 

Cost estimates are designated by classes, w hich correspond to a given phase of the design process. The 
least detailed classes of cost estimates are Class E and F. They are based on 1 -digit w eight based cost models such 
as parametric cost estimating relationships (CERs). If specific costs for components (propulsion systems or combat 
systems) are known, they are included The ACEIT model uses CERs. Class E and F estimates pro\ide order of 
magnitude estimation for concept design. At the end of concept design, a Class D estimate may be provided. Class 
D estimates pro\ide refined weight based cost and establish the basis for design-to-cost estimates for contracting. 
During prcliminaiy' design. Class C estimates are provided. Class C estimates are budget quality* estimates, but are 
still based on w eight based parametrics. However, these estimates increasingly incorporate engineering analysis of 
design characteristics. For instance, w ith the introduction of PODAC costing metliods. Class C estimates should 

Hope and Stortz, ‘‘Warships and Cost Constraints". Naval Engineers Journal . March 1986, page 41-43. 
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begin to reflect direct producibiliw cost impacts beyond simple shaping functions which are often applied to 
parametrically based costs. Additionally, life cycle cost models are being developed to provide cost analysis of 
manning, ILS, and operational impacts as well as development and production. For example, the ACEIT cost model 
is modified to provide differentiation of varying production rates and multi-year contracts. Class B estimates are 
provided during contract design. These estimates establish the cost ceiling for the acquisition (again by design-to- 
cost methodology' and typically, weiglit based costing models) by which contract bids are judged. Class B estimates 
are often referred to as Bid Evaluation Cost Estimates. Detailed cost estimates, or post-budget costs, are realized 
costs associated yvith material acquisition and compared to bid and contract cost estimates. 

There is an ever-increasing body of cost estimating tools, cost trade-off studies and cost-risk tasking. For 
modeling purposes, the growth of cost tasking is ignored relative to the baseline program. Baseline tasks (DDG-51) 
are shown below^ in Table 38. Inputs for dey eloping these tasks are primarily weight based. Therefore, cost tasking 
relies on design characteristics (hull, weights, structures, machinery' and combat systems) that are related to SWBS 
groups. For life cycle cost estimates, manning, ILS, and producibility are also incorporated. The output from 
costing is proyfded to programmatics as well as first order changes to those design characteristics that exceed cost 
thresholds for cost sensitivity such as structural weight and auxiliary' systems. 



Task Element 


Concept 


Preliminary 


Contract 


Detailed 


Functional 


Transition 


Zonal 


Production 


Independent Cost Estimate & Unit Cost Report (tCE/UCR) 


1 


1 


1 


1 


1 


1 


1 


Class D/E/F Cost Estimate 


1 


1 


1 


1 


1 


1 


1 


Program Life-Cycle Cost Estimate 


1 


1 


1 


1 


1 


1 


1 


Class C Cost Estimate 




1 


1 


1 


1 


1 


1 


Weight & Cost Engineering 






1 


1 


1 


1 


1 


Class 8 Cost Estimate 






1 


1 


1 


1 


1 



Table 38 Cost Estimates and Analysis Tasks 



Myron Ricketts, Manual for Na\ al Surface Ship Design Teclmical Practices , Na\ al Sea Systems Command, 
Washington DC, 1980, section 14. 



97 



5 Process Model Sectors 



The following sections provide brief descriptions of the primar\^ components of the naval ship design model. 
For specific model elements (equations and values) refer to the Vensim modeling code provided in chapter 8.7. A 
graphic representation of the design process model is shovvii in Figure 35. 

5. 1 Process Sector 

The basic structure for all s> stem dvmamics product development models is the rework (or work 
accomplishment) structure. The structure may have several fonns such as that shown in Figure 22 or Figure 34. 

The structure demonstrates that from an initial pool of work to do (TBD), work is accomplished at some rate. Based 
on a dvTiamically determined lev el of quality, some work is accomplished correctly and some requires rework. The 
incorrect tasks remain in error until discovered through a QA process and reassigned as work to do. 




Figure 34 Work Accomplishment Structure 

Several specific project models vv ere examined for applicability to the naval ship design process problem. 
These previously dev eloped models include the Ingalls Litigation Model (Cooper, 1980), Program Management 
Modeling System (PMMS) (Pugli-Roberts Associates, 1997), Software Project Model (Abdcl-Hamid and Madnick. 
1991) and Concurrent Development Model (Ford and Sterman, 1997). Each model was studied for behavior and 
policy elements applicable to naval ship design. Selected components of those models form the structural engine for 
the naval ship process model. Figure 36 shows this structure. 
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Figure 35 Naval Ship Design Process Model 



5 



c 







Figure 36 Naval Ship Design Process Model Work Accomplishment Structure 



5.1.1 Primary Work Flow 

Tlie stnicture in Figure 36 demonstrates an operational \ iew of the design process. At tlie beginning of the 
current design phase, some known level of baseline tasking is released as tasks to be done (TBD). Those tasks are 
assigned to the engineering staff and become work in progress (WIP). Based on an accomplishment rate (Comp 
Rate) tasks are completed. Tlie completed tasks eitlier require iteration (due to internal error discover)' or design 
spiral relationships) or review Tlie re\ lew ed tasks either require iteration (review error discover)) or release as 
approved tasks. Appro\ cd tasks are considered completed and not subject to fiirtlier action. Note that this 
assumption may fail to fully capture rescope impacts wliich occur \ cr)' late (higli levels of appro\ ed tasks) in the 
design pliase. The iterated tasks represent rework and arc accumulated for coordination (Coord Rate). Based on a 
coordination rate, the rework is released back to the work flow as WIP. The structure also reflects the potential for 
scope growth (rescope rate). Rescope tasking enters the flow tlirough TBD for assignment. 

5.1.2 Review and Approval Factors 

A key structure in the process is the inclusion of review and approval. For naval ship design projects, such 
review is required by law. However, the extent and duration is subject to interpretation Review is considered an 
internal activit)' performed at the program level and below. Primar)' participants arc program management staff. 
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activity staff (both NAVSEA and contractors) and interested parties. Approval is the acceptance of the design by 
external forces. Approval must include tliose organizations required to participate by law (DoN, DoD and program 
managers) and interested parties. As discussed in Chapters 1.1 and 4.4, the review process is a source of cycle time 
delay and growth. The required products for design review and the large numbers of review and approval levels 
were a primaiy^ concern to DAC study participants. During the DAC, data was gathered that described average 
approval and review periods for over 45 DoN projects. Additionally, limited data on CG-47 and DDG-51 approval 
and review periods was available. These values are shown in Chapter 8.5. Interviews (see Chapter 8.2) with 
process participants indicated that review and approval times (not error correction) are the primarv' sources of 
generated delays. As such, the model incorporates these delays directly as approv al and review periods through first 
order control 

6.1.3 Error Generation and Detection 

Errors form a significant source of feedback in a development process. As discussed in Chapter 3.1, 
generated errors (regardless of a specific cause) must be discov ered and reassigned to correct. In system dynamics 
models, error generation is a dvmamic e\ ent that may be coupled to forces such as schedule pressures, workforce 
experience, and fraction of Job complete. QA efforts are also chmamic with improved QA productivity occurring as 
the project approaches completion Functional forms for error and QA efforts relative to those forces can be found in 
Abdel-Hamid and Madnick, 1991^^^. 




Figure 37 Naval Ship Design Process Model Error Sector 
Figure 37 shows the error sector for the naval ship design model. Two d>Tiamic modifiers were chosen for 
error generation and discover} . First, errors are more likely in earlier design phases than later. As such, the chosen 

Abdel-Hamid & Madnick, Software Project Dynamics: an Integrated Approach . Prentice Hall, New Jersey. 
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error fractions (as a fraction of total tasks completed) reflects decreasing rates as the project approaches detailed 
design. Additionally, as the total error discovered increases, tlie fraction of new error decreases. In error discover\ \ 
these factors work in reverse; as the project matures QA improves and as total errors increase QA effectiveness 
increases. The selection of baseline error rates (20% in concept design to 10% in detailed design) w ere based on 
interviews with personnel at both NAVSEA and Bath Iron Works (BIW) (see Chapter 8.2). 

5.1.4 Design Feedback 

The one structure of the naval ship design model not found in other system chmamics models is that of the 
design feedback loop. This dynamic reflects the interrelationship of the 23 specific design disciplines participating 
concurrently in the design process. Using the DSM developed in Chapter 4.3, tasks are reworked at a rate consistent 
with the following criteria: 

• As task A is completed a fraction of that task is “undone” by concurrent work in tasks to w hich task A is 
dependent 

• Task A is “undone” at a rate not to exceed its own completion rate or 

• “Undone” at the fastest rate of all its input tasks. 

The feedback fraction represents the fraction of tasking that are “undone" by process concurrence. The value may 
be though of as either the average allowable margin for change at tlie given design pliase or as 1 minus the fraction 
of performance and cost lock-in (see Figure 5.) Those tasks that are sent to iteration must be coordinated to 
determine what data has changed and what errors must be corrected. The coordination rate is (like the approval and 
review dynamic) a first order control through TBCoord and the average coordinate period. 

5.2 Scheduling Sector 

5.2.1 Desired Schedule 

The concept of schedule encompasses the desired cycle time for the design project. It represents one of the 
three primary trade-offs of the project (Section 1. 1.) It is by the selection of schedule that all other model variables 
are estimated and controlled. For instance, fixing schedules and design products produces a required manning le\ el 
and the subsequent cost of those persomiel. Schedule is not fixed over the life of the project. Consider Table 39. 

The desired schedule for contract award was allow ed to slip many times over tlie course of the DDG-51 project and 
at increasing rates as the estimate date and the desired date converged. Table 40 further demonstrates the sliding of 
schedule dates o\ er the course of the project. 



103 



Date of Estimate 


March 15, 1983'^*" 


June 1, 1984* 


December 9, 199l‘"^^ 


Desired Schedule 


December 15, 1984 


January 10, 1985 


April 2, 1985 


Change from Previous Estimate 


— 


1 month 


3 months 



Table 39 Schedule Estimates for DDG-51 Contract Award^**^ 



Date of Estimate 


4/15/83 


6/1/84 


6/1/87 


12/9/91 


Concept Design Start 




8/1/78 






Senior Review 




2/1/82 






Command Review 




12/15/82 






Concept Design End 




3/31/82 






Preliminary Design Start 




3/31/82 






SCIB 




10/1/82 






Senior Review 




12/1/82 






Command Review 




12/15/82 






Preliminary Design End 




5/13/83 






Contract Design Start 




5/14/83 






DSARC 






8/26/83 




Baseline Freeze 






9/2/83 




Invoke Configuration Control 


7/22/83 




9/30/83 




Contract Design Circulation 


12/5/83 


3/28/84 


3/28/84 




Senior Review 


12/15/83 


5/15/84 


5/15/84 




Command Review 


1/15/84 


5/29/84 


5/29/84 




Contract Design Reading Session 


3/5/84 


6/1/84 


6/15/84 




Contract Design Signature 


5/25/84 


6/9/84 


6/29/84 




Contract Design End 




3/1/85 






Contract Award 


12/15/84 


1/1/85 




4/2/85 


Lead Ship Launch 




5/1/88 




9/16/89 


Lead Ship Delivery 




9/1/89 


7/1/89 


4/29/91 



Table 40 Key Program Dates and Schedule Shifts^"*^ 

To model this behavior, the following generic elements are applicable (Figure 38.) From an equilibrium 
condition (schedule gap is zero), assume a perturbation occurs and estimated completion exceeds scheduled date. 
Initially, gap increases, pressure to increase workforce levels increases, workforce increases, accomplishment rate 
increases, project duration decreases, estimated date decreases and gap decreases... a balancing svstem through 
estimated completion date. Simultaneously, as the estimated date exceeds the desired date, the desired date updates 
to match estimates. The time to change schedule represents the average time required to absorb half the schedule 
gap. As the desired schedule increases, the gap decreases, pressure to increase manpower decreases, manpower 
decreases and, ultimately, tlie estimated date slides further. . .a reinforcing s>stem through desired completion date. 



CAPT J.J. Fee (USN), US Na\y letter 50C/JJF Serial 5032-042. April 15. 1983. 

Naval Sea Systems Command, Ship Design Project Histories: Volume 11 1980-1989 . estimated edit date June 
1984. page 2.8-5. 

Joe Daley. PMS-400B Program Office, Wasliington D.C., correspondence dated December 9, 1991. 

See footnotes 138, 139, 140. 

^^^Ibid. 
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Based on the obsen ed sehedule (Table 40). the initial values for the baseline design model are established 
(Table 41.) The adjustment time, as input to an exponential deeay fnnetion, may be approximated as follow: 



Adj ustmentTime = 



TimeToCloseGap 

3 



The Time to Close Gap is the time to observ ed pliase end. Thus, an Adjustment Time of 12 months is eonsistent 
with the observ ed results. 



Time to change 




Figure 38 Generic Schedule Model^^^ 



Design Phase 


Concept 


Preliminarv’ 


Contract 


Lead Ship 


Manufacturing 


Initial Schedule Projection 
(months from start) 


36 


48 


60 


72 


78 



Table 41 DDG-51 Design Process Model Desired Schedule Initial Values 



The generie structure is reflected in the na\ al ship design process model as the schedule sector (Figure 39). 
Like the generic structure, tasks remaining are compared to the available manpower and nominal design rate to 
detenninc a projected completion date. This date is compared to the desired date to generate a gap. Based on the 
gap, adjustments are made to manpower, productivity and o\ ertime (see Figure 35 to observe those feedback links). 

One slight modification is noteworthy. Instead of measuring progress by what remains, nav al ship project 
managers measure progress by what is done. Specifically, the perceived tasks completed is a fimction of completed 
tasks (completed, rev iewed and approv ed). Tlie tasks to be done are then generated by comparing completed tasks 
to the expected total tasks for the current phase: initial tasks times the percent phase complete desired. Percent 



Jim Hines, “Molecules of Structiue Version 1.3", LeapTec and Ventana Svstems. 1997, page 85-86. 
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phase complete desired is the fraction of total tasks that must be completed to allow designers to proceed to the next 
iteration. This alternate structure can be found in other project management models.^'*'* 




Figure 39 Naval Ship Design Process Model Schedule Sector 

5.2.2 Phase, Review and Approval Initiation 

Due to the inclusion of multiple design phases (concept design, preliniinar>' design, contract design, lead ship 
detailed design and manufacturing engineenng design) and multiple stages within a single phase (tasks in progress, 
tasks under review, and tasks under approval), it is necessarv' to establish a structure to initiate subsequent sequences 
and close previous ones. Tlie phase initiation structiue is shown in Figure 40. Based on the comparison of appro\ ed 
tasks to total tasks for the phase, the percentage complete is generated. Tliat percentage is compare to the required 
percentage necessar>' to proceed to tlie next phase. Wlien the current phase percentage is satisfied, a Boolean 
operator (Current Phase) is set to 1 for the next phase to start the release of new tasks. Simultaneously, Current 
Pliase is set to 0 for the pliase being completed. This prevents the release of further tasks and resources to the 
completed phase. A parallel structure is present for release of tasks to rev iew (completed tasks become available for 
review) and approv al (reviewed tasks become available for approv al). Hovvev er, unlike the Current Pliase variable, 
approval and review operators do not stop previous segments from continuing. 



Abdel-Hamid & Madnick, Software Project Dynamics: an Integrated Approach , Prentice Hall, New Jersey, 

106 




Figure 40 Naval Ship Design Process Model Phase Initiation Structure 



5.3 Productivity Sector 

ProductiviU’ is the measure of the effective rate by w liich a\ ailable manpower is able to complete assigned 
tasking. Figure 41 show s an example of a generic producti\ ity calculation. This structure shows how* a nominal 
productivity' level (normal productivity) is influenced by factors such as fatigue, schedule pressure (or schedule gap) 
and work adequacy (or fraction of design change). ProductiviU' as shown here is measured as the number of tasks 
completed per person per unit time. 

Producti\it>^ is a \ eiy' difficult quantiU^ to measure. This is true because observ ed productivit>' represents the 

work rate after the modifications by dynamic influences (fatigue, schedule pressure, etc). As such, nonunal 

productivit} represents a fraction \ eiy' different than that w hich is observed. Consider the naval ship design process 

model productivity functions (Figure 42). Like the generic structure, numerous dynamic influences are included: 

fatigue, organizational size, and schedule gap. Tlie average design rate is included to represent the nominal 

productivity level. This value actually represents tlie observed rate for a given project and is calculated as: 

^ TotalTasksPerDesignDisciplmePerPhase 

AverageDesignRate = 

TotalPersonnelPerDisciplmePerPhase • PhaseDuration 

This rate would represent the value used by program managers to assess progress or model tlie process in 
scheduling programs (CPM/PERT models). For the DDG-51, the average design rates are calculated and shown in 
Chapter 8.5. However for the process model, this rate must be adjusted to reflect the actual baseline rate absent of 
dvnamic influences. The obsened rate is multiplied by an adjustment (Adjust Rate) in tlie nav al sliip model to 

provide calibration of the observed rate in order to reflect the nominal rate of productivity. 
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Figure 41 Generic Productivity Structure 




Figure 42 Naval Ship Design Process Model Productivity Sector 

With the effective productivit>’ rate established (Net Productivit>' Rate), it is multiplied by the effecti\ e 
persomiel level to provide a completion rate (Comp Rate) by which tlie pool of WIP is completed. Note that the 
Comp Rate has a ceiling rate (maximum rate of completion) provided by the first order feedback tlirough WIP and a 
minimum completion time for a single design task. That minimum rate is estimated as 1 month in the model. 

A similar structure is shown for the rate at winch tasks in rework (TBCoord) are completed. Additionally, a 
staicture for tlie initial assignment of tasks is provided based on the perceived completion rate for available tasks 
(personnel assigned times net productiviU' rate of those persomiel) and the desired period of design completion 
(Design Phase Duration). 

Tlie effective personnel available for assigmnent is modified by three inputs. First, the basic manning level 
represents the total number of NAVSEA and contractor persomiel assigned to a particular design pliase and design 
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discipline. Ho\\e\ er. not all men are created equal. Rather, a second modification is necessar>^ to reflect the 
differences in project experience among the personnel. It is assumed tliat altliougli all engineers and designers are 
equally skilled, those who are with the project for more than six montlis are more productive (by an assumed factor 
of 20%) due to experience with the design material and the design organization. Finally, as schedule pressure 
increase, design managers may begin to autliorize o\ ertime work for personnel. As a first order dynamic, overtime 
has the effect of fractionally increasing the personnel level (by as much as 150% for limited durations) without tlie 
need to actually hire new , inexperienced designers. How ever, tlie short tenn impacts of overtime may be negated by 
second order fatigue impacts. 

5.4 Manpower Availability and Assignment Sectors 

5.4.1 Naval Ship Design Organization and Resource Structure 

The Design team is characterized by government and industiy^ participants. Tlie level of participation 
transitions from mostly go\^ernmental to mostly commercial over the course of the program. Figure 43 show s tlie 
increasing fraction of contractor to NAVSEA effort tliat took place o\ er tlie course of the DDG-51 design program. 
In tliis case, the NAVSEA levels were relatively consistent througliout the program, but the participation of 
contractors (both private and other government agencies) increases exponentially during the program. The impacts 
of this transition (shown in Figure 5) are discussed. Such transitions are natural when considering the goal of each 
stage of the process. Tlie organization tliat results from the transitions and manning levels must reflect by the need 
to manage the design and to assign appropriate resources to design tasks. As presented in Chapter 4. the design 
tasks are natiually broken into design disciplines (23 are listed) Tliese disciplines contain the structure for 
manpower organization and design interfaces. A comparison of design disciplines and mamiing levels is shown in 
Figure 44. 

Consider the organizational charts for the DDG-5 1 program (Figure 45, Figure 46, Figure 47, Figure 48). 

Each element of the organization represents a portion of the design process structiue captured in the design 
disciplines. For instance, Figiue 45 represents the programmatic organization and its linkages to operational 
requirements generation (CNO), engineering resources (NAVELEX, NAVSEA and SYSCOMs), and the design 
itself (Ship Design Manager and Combat Systems Engineer). Tlie Ship Design Manager (SDM) and his/her 
organization is show n in Figure 46. This organization reflects the different task groups (machinery engineering, hull 
engineering, integration and specifications, etc) luider w liich the specific task disciplines are completed. Figure 47 
shows the combat integration and design organization and its linkage to the design througli the program manager 
and SDM. Finally, Figure 48 demonstrates the organization for cost assessment and control. Note the close ties 
between cost and weight necessitated b>- the costing models of that time. For early design stages, the participation 
of shipbuilders is limited as shown in Figure 49. 
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Design Effort 

(DDG-61 Contract Design History, Rev June 1987) 




May-79 Ocl-80 Feb-82 Jul-33 Nw-34 Mar-36 



Figure 43 DDG-51 Total Design Effort^^^ 



Data is complied from documentation listed in Chapter 8.4. 
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Figure 44 DDG-51 Manpower Transitions and Design Task Growth'^^ 

As the design transitions to industr> , the organization must likew ise transition. The government design team 
in later stages includes a reduced level of those organizations discussed abo\ e and resident Superv isor of 
Shipbuilding (SUPSHIP) organization that provide contract o\'ersight. The industr\^ participants (coordinated 
through the shipbuilder) include:^"*^ Shipyard Management Teams (Design Management), Functional Design Teams 
(Systems Engineering and Component Integration), Zonal Design Teams (Transitional Design CAD extraction and 
Zonal Design and Manufacturing Design Extraction), and the Materials Management Team. Within detailed design, 
shipbuilders le\ el load teams to maximize resources (teams, designers and engineers, computers) vvlule pro\iding 
production facihties with design products in a timely fasliion. Detailed design products must be completed Just in 
Time (JIT) to accommodate design changes with minimal impact to completed design products. In other w ords. 
design products are not completed miless manufacturing is ready to proceed. Typical design effort for the DDG- 
51 included in the model consists of a team of 372 engineers and designers w orking in two shifts (244 in first shift, 

1 13 in the second.) Tlie designers are organized into 8 zonal teams: 3 hull specials teams, 3 machinery' specials 
teams, and 2 electronic (combat s> stenis) specialty teams. The teams work eiglit zones concurrently in design and 
no more tlian four zones transitioning to the nex1 subphase at any given time. Teams to provide logistics 



C. R. Lloyd, “Design Process for the AEGIS Destroyer Program”, Presentation, Bath Iron Works D87 Class 
Design Office, November 1 8, 1 997. 

Da\ad Hinds, interview at Bath Iron Works, Brunswick, ME, November 1 5, 1 997. 

Ill 




management (ordering and parts management) and design management (ECP management, mformation 
management, etc) are included. 




Figure m. ddg 51 sh!? design command and phogram organization 



Figure 45 DDG-51 Ship Design Command and Program Organization'^’ 



Andy Summers. Contract Design History for the Guided Missile Destroyer (DDG 51 Class) , Na\ al Sea Systems 
Command Washington DC, June 1987. page 2-27. 
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FIGURE 2-2. DDG 51 SHIP DESIGN TEAM ORGANIZATION 



Figure 46 DDG-51 Ship Design Team Organization^^” 



Ibid, page 2-28. 
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FIGURE 2-3 COMBAT SYSTEM ENGINEERING ORGANIZATION 



Figure 47 DDG-51 Combat System Engineering Organization^""^ 
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Ibid, page 2-29. 
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FIGURE 2-4, RESOURCE CONTROL TEAM ORGANIZATION 



Figure 48 DDG-51 Resource Control Team Organization*®’ 



Ibid., page 2-30. 



115 




i fi/*VScA =0C 

: JllitCiO'! Zr 




fiEsauKc; ; 
CCfi'RCL I 
ttAY 



DiliLCiCK 

L-JivANCE 



FIGURE 2-5. SYSTEM ENGINEERING TEAM RELATIONSMIP 
TO DDG 51 DESIGN TEAM 



Figure 49 DDG-51 System Engineering and Ship Design Team Relationship' 



Ibid., page 2-31. 
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5.4.2 Manpower and Adjustments 

The general dynamic behavior of resources is characterized by step increases in manpower from Concept 
tlirough Detailed Design, ascending and declining effort within each phase, and small numbers of governmental 
personnel outsourcing large fractions (50 to 75%) of design effort to contractors. This is captured in the naval ship 
design process model by splitting manpower into two flows: NAVSEA and Contractors. Figiu*e 50 shows this 
structiue. NAVSEA personnel are those personnel that are considered free to the program from a budget stand- 
point. However, there are fewer NAVSEA personnel a^'ailable and the first order assignment of personnel is more 
difficult as fewer become a\'ailable. Contractor persoimel flows include all those personnel that require budget 
e.xpenditures to work. They include other go^’emment agencies (OGAs) such as tlie Nuat labs, ship design 
contractors such as JJMA or AME, and shipyards such as BIW. As discussed previously (see Cliapter 5.3). the 
flow s explicitly include the maturing of designers over tlie course of tlie project. 




Figure 50 Naval Ship Design Process Model Manpower Sector 
Given the available persoimel, it is necessar}^ to determine the desired number of persomicl to be added or 
remo^ ed from those flows (Figure 51) and the distribution of persoimel requirements between go\ ernment and 
private resources (Figure 52). Several noteworthy properties are demonstrated in these structures. First, overtime is 
modeled to reflect tlie means by which managers assess overtime needs (Indicated Overtime Required and the Effect 
of Schedule Gap on Ov ertime) and the impact of overtime for extended periods on productivity (Fatigue). Fatigue is 
a stock because the accumulation of fatigue does build oxer time and takes time to decrease again. Secondly, 
manpow er loading levels (seen Figure 43) show decreases in both total effort and percentage of contractors w hen 
approv al stages begin. Table functions for the effect of approval pliase on desired manpower and on NAVSEA 
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fractions are also mcludcd. The model detemiiiies a desired manpower level, adjusted by these effects, and uses tliis 
value to requisition new personnel or release personnel based on a perceived manpower gap (manpower shortage). 
The shortage is distributed by the desired fraction of NAVSEA persoimel to be hired. If persoimel are to be 
released tlie model attempts to release new personnel prior to experienced manpower. This effect is included based 
on inter\'iews with managers from NAVSEA and BIW 




Figure 51 Naval Ship Design Process Model Desired Manpower Sector 




Figure 52 Naval Ship Design Process Model Manpower Allocation Sector 
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5.5 Financial Sector 



The financial sector is the link between the design process model (schedule) and the available design budget. 
This process fits within the context of the formal DoD budgeting process: the Planning, Programming and 
Budgeting System (PPBS). The PPBS is a multi-year budgeting s\^stem that addresses all areas of military^ budget 
including both operational expenditures and acquisition. Program managers must interact with the PPBS to secure 
funding for future design and acquisition costs and continue to justify^ current expenditures. 

The sy stem consists of three distinct phases. During the Planning Phase, mid term and long range defense 
goals are assessed against perceived threats. This is similar to the chmamics seen in Chapter 2. 1 . Based on results of 
this analysis, the National Security Council issues the National Military Strategy Document (NMSD). The 
document is issued in July of odd numbered years. Between then and November 30^ of the same year, the 
document is reviewed and re-issued as the Defense Planning Guidance (DPG). The document defines the fiscally 
constrained force structure into which the program manager must attempt to secure a portion of funds. 

The second phase is the Programming Phase. This phase establishes the allocation of funds to the specific 
force elements tliat must be supported. Tliere are eleven force elements which include strategic forces, general 
purpose forces, research and development, etc. The goal of this phase is to establish the optimized mix of 
manpow er and equipment required to satisfy the national defense posture. By April of the ne\1 year (even year) 
Program Objective Memorandums (POMs) are prepared. The POMs reflect "a detailed expression of proposed 
programs by program element, schedules and funding 6 years into the future, with force levels 3 years beyond 
that. . .Each POM submission is a modification of the approved PfDP (Future Years Defense Program), updated to 
reflect current guidance from OSD (Office of the Secretary of Defense), with 2 fiscal years being added during each 
(POM) cycle.”^^'^ By September, all POM issues are debated and appro\ ed with the Secretary of Defense appro\ing 
these submissions as the basis for the Budget Estimate Submission (BES). Tlie program manager, based on the 
current and future needs of his or her program, seeks to influence the POM submission to gain additional funding for 
the program as necessary. However, the nature of this S} stem means tliat actual funding requests are not realized for 
at least 2 years from submission and possibly 4 years if tlie submission falls at the end of the POM cycle. 

The final phase is Budgeting. From September tlirougli December, tlie BES and POM are assessed for 
categorical allocations to five pnmaiy^ budget categories: RDT&E, Procurement, Operation and Maintenance. 
Military Persomiel and Militaiy' Construction. During tliis period final budget adjustments known as Program 
Budget Decisions (PBDs) are performed to account for cost factors, risks in projections, the timing of related events, 
jointness of requests, and uniformity. Tlie final budget is submitted to tlie President the first Monday after the 3'^'^ of 
January in the next year (odd). The budget is debated and approved for activation the following fiscal year (Clctober 
of the year of submission). 



Defense Systems Management College, Tlie Program Manager's Notebook, Fort Belvoir, VA, June 1 993. 
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The obvious delays in the timescale of the PPBS must be accounted for in the development of the naval ship 
design model. Coupled with the target profile for engineering expenditures during the design process, the PPBS 
manifests itself as a funding delay when increased budget needs arise to meet design schedule deadlines. Consider 
tlie topical engineering cost profile for a surface combatant program show n in Figure 53. Based on past cost profiles 
(such as is shown below), the desired schedule and the complexity of the design program (total tasks to complete), 
the program manager must submit a budget request through the PPBS. Funding is not granted in excess of 
perceived needs, so the program manager are constrained to a fixed schedule and budget. However, as process 
dynamics cause the schedule to slide and the engineering cost fluctuate as does manpower loading (Figure 43), 
funding shortfalls can occur. The time required to overcome the shortfalls is equivalent to the duration of the PPBS. 

I 

Engineering Cost Profiles • 




Design Phase Start Date 



Figure 53 DDG-51 Engineering Expenditures'^^ 

Figure 54 shows the chaiamic budgeting and allocation flow for the naval ship design process. The delays 
from the PPBS are modeled as a first order dela}' through Change to Budget and Time to Change Budget. The Time 
to Change Budget is set to 2 years to reflect the average PPBS cycle time. The Funding Period and Fiscal Counter 
model the fiscal allocation of funds to the program. Actual spending becomes a function of total effective 
manpower costs (i.e. total contractors plus o\ ertime). Note tliat the model explicitly capture overhead costs. These 
costs are included in the value of tlie contracting fee ($6597 per engineer per month).'^^ 

Funding shortfalls occur as two dynamics. First, a funding gap is created that is relie\ ed by first order control 
tlirough Cliange to Budget and subsequent flow through tlie fiscally controlled Program Budget Rate. The second 
effect is the temporaiy decrease in funding to contractors (i.e. release of contractors) and the increase of NAVSEA 
engineering efforts to compensate. As budget levels rise once more, these trends reverse. Should a funding surplus 
occur, tlie d} naniic is reversed: the budget decreases over time and the program assigns increasing le\ els of 
contractors to consume the surplus. 

Naval Sea Systems Command, Ship Design Project Histories: Volume II 1980-1989 , estimated edit date June 
1984, page 2.8. 

Ibid. FY1996 dollars projected from 1985 engineering cost estimates for contractors. 
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The final element of the model is the explicit modeling of contract t\pes. Within llie contracting 
environment, program managers have the option of awarding new Requests for Proposals (RFPs) or using existing 
contracts through other program offices. There are ad\ antages and disadv antages to each. New awards prov ide the 
manager (PM) with a dedicated contract, tailored to the current program with no overhead costs imposed by external 
authorities. However, the RFP process can take as long as 18 months to establish and begin actual design work. For 
tliis reason the PM may offer to fund an existing contract being managed by a NAVSEA directorate or other 
program office. Such an approach offers rapid access to contractors and design resources. How ever, the managing 
office imposes an ov erhead charge of 10% or more of the design costs. Additionally, the contract may not be 
tailored to the particular design problem being studied. As sucli, the PM must decide on an appropriate policy for 
allocation of contract tvpes. In tlie model, these allocations are fixed as percentages of contractor assignment. The 
percentages transition to RFPs as the process matures. 




Figure 54 Naval Ship Design Process Model Financial Sector 
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6 Hypothesis Testing, Modeling Results and Conclusions 



6.1 Baseline Model Results 

The desired behavior for the baseline model is to match the levels and dynamics of the DDG-5 1 program. 
Obtaining specific data for such an effort is difficult. As was noted in the DAC stud>^ program management 
statistics are highly variable in quality and availability, particularly with respect to manpower efforts. Specific 
documents with such information have been published. These include several NAVSEA documents: the DDG-5 1 
Guided Missile Destroyer Preliminary Design History , the Contract Design History^ for the Guided Missile 
Destroyer (PPG 5 1 Class) , and the Ship Design Project Histories: Volume f II and III . From these documents, 
manpower and budgetary trends can be extrapolated Figure 55 illustrates the NAVSEA effort for several recent 
design programs. Strategically, NAVSEA has reduced (over time from FFG-7 to CG-47 to DDG-5 1) the numbers 
of go\ emment personnel assigned to the program. Operationally, the graph demonstrates increasing engineering 
efforts through each design phase with se\'eral d> namic rises midway through each program, declines at the end of a 
phase, and an extended level of decrease at the end of contract design. 




Figure 55 Early Phase NAVSEA Personnel Effort for Surface Combatant Design Programs^^^ 
Figure 43 shows the significant difference in numbers of government and contractor personnel. Tlie 
NAVSEA effort is small compared to that of Other Government Agencies (OGA) and contractors. Generally, the 
trend for each categoty of personnel follow s the total trend effort for the program. There are some unusual 
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vanations in contractor and OGA effort. Howe\ er, as each of these t\pes require budget expenditures to acquire. 
The variations represent a choice by the program manager to select one t\pe of contractor over the other. 

Another noteworthy d\Tiamic is the transition between design disciplines over the course of the project. 
Recall the design disciplines and design products discussed in Chapter 4. Consider the trends shown in Figure 56. 
In early stages of design, programmatic interfaces dominate along with a significant effort in s\^stem performance 
assessment. Other engineering efforts provide input to these categories, but the delivered products are substantially 
less. This reflects the early goal of design to determine requirements and needs. As the program matures, 
increasing effort is in high risk design categories such as combat systems and marine s> stems integration. In the 
final stages of the design process, very specific efforts in component level definition (hull structural drawings, 
arrangements drawings, machineiy^ arrangements, MELs and parts lists) dominate the engineering effort. 




Based on tliese trends and tlie d> namics discussed in Chapters 4 and 5, tlie na\ al ship design process model 
was adjusted to match the baseline beha\ior of the DDG-5 1 program. Figure 57 show s the model results for total 
assigned manpow er compared to the DDG-5 1 program. The model results were calibrated once by adjusting the 
nominal producthity rates (Adjust Rate, see Figure 42) to match project duration to the DDG-5 1. These results 
demonstrate the effectiveness of the chmamic model to capture the chmamic behavior of a complex process. 
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Data is complied from documentation listed in Chapter 8.4. 
Ibid. 
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Although not all levels are captured precisely, the d>Tiamic events are. Note tlie agreement of the model and data 
from months 35 to 45 and from months 50 to 90. 




Figure 57 Initial Baseline Results from the Naval Ship Design Process Model 
The differences between the model and data may be accounted for in se\ eral ways. First, note that the data 
shows initial manpower levels of over 50 personnel. Tliis is deceiving. The program had actually started concept 
studies as early as 1978, Tlie model starts from 0 persomiel in 1980 (milestone 0 for the program). Another issue 
with the data is that it implies all personnel assigned to tlie project are \\ orking on the project 100% of the month. In 
reality. NAVSEA persomiel and contractors on existing contracts may have \\ orked only a fraction of the time on 
the DDG-5 1 and the remaining time on other projects. Ajs such, the data o\ erestiniates mamiing levels . . . particularly 
in early design phases. Finally, the model was only calibrated using a single variable. Given more time and 
resources, the model could be calibrated more accurately using sensitivity analysis of all model constants and 
tlirough further refinements of the model beha\iors. 

These minor issues do not detract from the value of the results. The model does capture the process 
dynamics. This alone is worthwliile as it pro\ ides insight into the causes of specific process beha^iors. For 
instance, tlie oscillations at month 45 and month 57 correlate to the end of fiscal cycles where funding shortfalls 
occurred. Armed with this prediction, a program manager may be able to negotiate a budget increase to pre^^ent 
future oscillations and subsequent schedule shifts. Thus, the model pro\ides useful results and can be used 
effectively to assess specific h\potheses. 
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6.2 What if CAE/CAD/CAM Are Used? 



The first h>pothesis examined with the model is how the application of computer based design tools effects 
the process dynamics, manpower loading and duration. In earlier chapters, some specific dynamic impacts of 
computer aided engineering, design and manufacturing (CAE/CAD/CAM) were addressed. Computer based design 
reduces error rates by allowing automated interference checking and QA of design products. Sev eral shipbuilders 
(BIW, Newport News Shipbuilding) have reported these improvements. However, reduced errors rates hav e not 
come without serious growing pains. At BIW, the use of early \ ersions of CAD resulted in very high false error 
rates, a false error being the designation of an interference or blockage in the CAD model when no such problem 
exists. From 1991 tlirough 1997, the engineenng division used 3 rev isions of the CAD software, with false error 
rates per zone per design review decreasing from an average of 1000 in 1991 to 100 in 1994 to 10 or less in 1997. 
Although these rates reflect exponential improvements, the five years of learning and adjustment were difficult to 
justilA-.'^^ 

Other organizations hav e claimed substantial reductions in design time with CAD s}^stem usage. The 
Daewoo Shipyard of Korea installed a CAD svstem to perform structural design. Table 42 shows the trends in 
usage of that s> stem at Daewoo. From the data, it is quite apparent tliat the organization was committed to CAD 
modernization. Tlie number of computers was increased while the number of designers and the design duration 
were reduced. Could these results be realized for the nav al ship design process? 



Item 


‘89 


‘90 


‘92 


‘94 


No. of Workstations 


10 


40 


60 


82 


No. of Designers (No. using Workstations) 


190 

(20) 


156 

(90) 


156 

(110) 


164 

(118) 


Computerized Drawings (%) 


26 


50 


92 


96 


Detailed Design Period (months) 


7.5 


7.0 


6.0 


5.5 



Table 42 Performance Status of Steerbear-Hull Design System at Daewoo Shipbuilding’^*^ 

Suppose a specific CAE/CAD/CAM svstem is proposed. Such a svstem provides an integrated design and 
data management env ironment for the design process. Based on the Daewoo experience, system designers adv ertise 
the following attributes for the system: 

• Error rate is reduced by 50% (computer integration and design automation should reduce errors) 

• Error discoverv^ is increased bv 50% (CAD softw are provides explicit interference detection) 

• Experience (learning) time is increased to 6 months* (computer svstems do require time for training and 
familiarization) 

• Coordination rate is 50% faster (data transfer ranges from instantaneous with a product model to 
improved with email). 

David Hinds, interview at Bath Iron Works, Brunswick, ME, Nov ember 15, 1997. 

Chris Keimison, KCS Users Meeting Minutes, Kockums Computer Systems, Annapolis, MD, October 31, 1997. 
David Hinds, inteniew at Bath Iron Works, Brunswick, ME, Nov ember 15, 1997. 

125 



Based on these properties, a model run is developed. The results are shown compared to the baseline run in Figure 
58 The result of these changes is a 13 month reduction in the total design process. This is consistent with the 
results seen for Daewoo Shipbuilding. Some dynamics are particularly noteworthy. The concept design process 
does not appear to change. The preliminaiy design process begins slightly earlier, but really takes off over the 
baseline case by month 30. Specifically, the design interactions are improved by faster coordination and reduced 
errors. Thus, more tasks are available for final iteration in prehminary design at an earher point. The contract 
design starts 5 months earlier and detailed design is able to start 8 months earlier. Thus, the apphcation of computer 
design, applied to a few specific variables (error rates, learning and coordination) pro\ides over a one-year cycle 
time reduction. Note, however, tliat the process did not reduce the number of personnel and even increased 
manpower le\ els in early stages. 



Graph for Net Personnel 




Time 

Figure 58 Comparison of Baseline Mode! to CAE/CAD/CAM Hypothesis 
What if the ad\ eitised improvements are not fully realized? Such a circumstance is consistent w ith the 
implementation difficulties described previously for BIW. Specifically, suppose the error rate from baseline 
methods is only reduced by 25% vice 50%. The model results for this case are shown in Figure 59. The results 
demonstrate that the process duration is not sensitive to a change in error rate. However, the number of personnel 
required to mauitain tliat schedule, particularly in contract and detailed design, is very sensith e with a 12% increase 
in personnel assigned over the project. As a result, manpower costs increase by over $30 million due to the 
unrealized potential of the CAD sy stem. 
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This example indicates the power of system dynamics modeling to analyze schedule risks 
associated with process improvements. 



Graph for Net Personnel Assigned 




Net Personnel Assigned : 25% Error Manpower 

Net Personnel Assigned : 50% Error Manpower 



Figure 59 Sensitivity of CAE/CAD/CAIVI Hypothesis to Error Rate Improvements 



6.3 What if Concurrent Engineering and IPTs Are Applied 

Concurrent Engineering and IPTs are proposed as methods to improve responsiveness of the design process. 
Previous discussions examined some specific dynamic impacts of concurrent engineering. IPTs, and IPPD. The 
ability of engineers to effectively communicate witli one another should reduce tlie number of design iterations 
required for convergence. Additionally, concurrent engineering front loads many design tasks earlier in the process 
such as producibility. 

For this case, suppose process improvements are advertised to provide the following process modifications: 

• Error discover}’ increased by 25% (teaming will provide continuous data exposure to multiple designers 
and disciplines) 

• Coordination rate is 100% slower (due to communication overhead costs) 

• Design feedback is reduced by 50% (teaming provides better know ledge among designers of task 
interaction impacts and comnumication of data trends) 
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• Approval and Review periods are reduced by 50% (teaming can provide interim communication of 
design requirements, attributes and effectiveness throughout llie process rather than during specific 
approval and review periods). 




Figure 60 Comparison of Baseline Model to Concurrent EngineeringAPT Hypothesis 
Applying these process modifications to the model pro\ides results as shown in Figure 60. These results 
show^ a 16 month reduction in tlie total design process Additionally, the net personnel assigned for the entire project 
(integration of the graphs) is decreased by 10% Tliis is an expected benefit from the use of cross-disciplinaiy 
design teams. Some of the chiiamics are particularly interesting. All the design phases occur faster and witli fewer 
persomiel. Tlie faster design penods allow' the process to better weather budget transitions by compacting tlie design 
phases (preliminaiv' and contract design) into periods of about 12 months each Tlie preliminaiy design process 
begins slightly earlier, but really takes off over the baseline case by month 30. Finally, the lead ship design occurs 
so much more quickly tliat the manufactunng design is actually delayed (represented by the saddle in the curv e) to 
await the JIT pull from production. Generally, we can conclude tliat tlie application of teaming in design process, as 
applied to a few' specific vanables (error rates, design feedback, approval schedules, and coordination) provides 
almost a one-aiid-a-half-year cvcle time reduction and overall manpower reductions. 

As with the CAE/CAD/CAM example, sensitivitv' analysis provides insight for nsks to program performance. 
In this example, suppose design feedback is only reduced by 40% vice 50%. Such a circumstance would occur if 
design requirements were continually changing such as during the end of the Cold War. The result is a lengthening 
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of the design process by 3 months, a 4% increase in manpower costs and an increased requirement for personnel 
during concept design. Again, sensitivity pro\ides the program manager with a tool to assess the expected impacts 
and risks of proposed process improvements. 



■1.1 
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f • ■» 
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Conclusions and Future Work 



7.1 Conclusions 

Most schedule analysis tools (PERT, CPM, DSM) only provide the ability to capture hard process vanables 
such as design concurrence or phase durations. These operationally and statistically based methods fail to capture 
the dominant dynamic influences (human factors, error propagation and design feedback) that ultimately lead to 
schedule growth. Additionally these methods do not accurately reflect non-linear impacts such as overtime, fatigue, 
schedule pressures and learning curv es (see Chapter 1.1.1). For these reasons, the naval ship design process model 
is necessarv' and useful. System dynamics modeling provides one of the few means to assess process improvements 
that must incorporate not only architectural changes to the process, but the responses of real people to those changes. 
The obvious physical relationships of naval architectme. marine engineering, combat systems engineering and 
systems engineering are explicitly modeled. Cost constraints and policy reactions are captured. These impacts are 
captured in many other sv stem d> naniics models as well (see Tan and Bligh, 1 998 and Rodrigues and Bowers, 
1995.) However, these models do not capture the issues of multi-functional design, design feedback or program 
policies unique to naval sliip design. For this reason, the inclusion of the DSM structiue in the naval ship design 
process model is necessarv . 

The naval ship design process model (see Chapter 8.7 for the baseline model) contains the necessary' detail to 
capture the dynamics of a ship design program. Specifically, the DDG-51 program behavior is captured (see 
Chapter 6.1). As the DDG-5 1 program is now almost two decades old, not all baseline variables are appropriate for 
use with current design programs. 

For instance, there is a trend to shift greater lev els of system analysis into concept design and to more fully 
develop the concept variants presented for AoA consideration. By this trend, concept design in the 1990’s 
increasingly examines details reserved for preliminarv' design in the 1980’s. To accommodate this trend model 
variables for initial tasks levels must increase in the concept design phase to reflect the increased design analysis. 
Additionally, the introduction of integrated design environments increases productivity relative to specific design 
tasks. This is reflected m the trends shown previously in Table 42. However, as the level of analysis increases more 
rapidly than productivity, the resultant design rate may actually decrease. Such specific modifications to variables 
are necessary' to assess modem programs with tlie naval ship design model 

Despite the need for changing variables, the generic structure of the nav al ship design model (see Chapter 5) 
is accurate and does reflect the policy and process mechanisms contained in the ship design process. Thus, with 
modifications of variables consistent with current design process trends (see discussions in Chapters 4.4 through 4.9) 
and calibration of those variables, the model is applicable to ship design programs like the DD-2 1 or C VX. 

Furtlier, the baseline model provides a structure to judge the impacts of potential process improvements and 
tlie risks associated with the assumptions of those improv^ements. As demonstrated in Chapters 6.2 and 6.3, gains in 
cycle time and manpower reduction are sensitive to the assumptions of the proposed improv ements. Program 
managers can test assumptions and design the process organization to optimize schedule perfomiance. Additionally, 
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the program manager can use the model to trade-off cycle time against mission effectiveness and cost as determined 
by their respective analysis methods (see Chapters 1.1.2 and 1. 1.3). 

7.2 Future Uses and Work 

The naval ship design process dynamic model has three potential future uses: 

1 . Testing of specific management policies and process improvements 

2. Understanding of the behavioral forces at work in a process 

3. Prediction of future trends 

For policy testing, the model provides a means to test and optimize a management plan (such as when to 
allow schedule sliift or what fraction of NAVSEA personnel to inv olve in a project.) However, a note of caution is 
necessaiv . The full use of any model for policy implementation must be contingent on the support of all process 
participants. Specifically, if knowledgeable personnel have not reviewed the model’s structure and behavior, it 
implementation will be flawed (i.e. tlie dvnamics are correct but the model structure is not tangible or operationally 
accurate.) The result would be accurate baseline behavior but inaccurate hypotheses. As such, continuous 
comparison of the model with observ ed results must take place. It is in this manner that the model can provide 
understanding of behavior forces. 

The model can also be studied to reveal behavior forces within the design process. Tlirough constant dialog, 
process participants and modelers can begin to recognize the causes of cycle time growth, the dvmamics of 
undiscovered errors, the effects of personnel changes on the process, and a multitude of other process behaviors. As 
managers change their mental models of the process to reflect more accurately the dynamic impacts of their 
management decisions, process improvements can be better implemented. Additionally, process authorities are 
better armed with tools to address critics and combat constraining externalities. 

Armed w ith accurate models and xmderstanding of those models, process managers can begin to predict and 
gauge the future trends of process improvements. As demonstrated in Chapter 6, initial results for improv ements 
such as IPTs and SBD liave the potential to significantly reduce cycle time. The next step is the calibration of the 
model to a current program (such as DD-2 1) and monitoring the expected results against obscrv ation. In this 
manner, a program manager has the necessarv^ metrics to modify management policies before critical thresholds 
(spiraling cost or schedule growth) are reached. 

Future modeling work to support and implement the above listed uses include: 

1 ) Discuss the model with program participants. Calibrate and validate critical dynamics such as cost impacts, 
scheduling methods and manpower allocation. 

2) Integrate the model with other dvmamic models (McCue, 1997) for analysis across design and production. The 
naval sliip design process model may ultimately be incorporated in a life cycle process analysis. 

3) Develop dynamic models for externalities (arms race dynamic, etc) and incorporate these dynamics 
endogenously to the model. 

4) Refine the model to 

a) improve manpower allocations for task coordmation and QA. 
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b) improve Program Plamung Budgeting System (PPBS) components relathe to cost 

5) Obtain improved baseline. comparati\ e data by 

a) examining additional metrics (other than manpower levels) at concept and prehminary' design to reduce the 
inaccuracies of collected data 

b) examining d> namic fluctuations of detailed design manpower levels from shipy ards and SUPSHTP offices 

6) Perform dedicated case studies to analyze hypotheses such as 

a) the impact of shifting design transition from government to industry earher in the process 

b) the dynamic impacts of scope growth in an open architectiu'e design 

These model improvements will provide greater fidelity and usefulness of the model for future use in 
assessing the sy stem optimization and dynamics of the naval ship design process. 
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8.3 Glossary and Abbreviations 



3-D Product Model - Captures all of the information needed to desenbe a ship 

AoA - Analysis of Alternatives, an analysis of the costs and operational effectiveness of altcmati\ e material sv stems 
to meet a mission need and tlic associated program for acquinng each alternative. 

ASR - Alternative System Review 

ASR - Acquisition Stratcg>' Report, describes the acquisition approach to include streamlining, sources, competition 
and contract t>pcs throughout the period from begimiing of Phase I. tlirough end of production. An aimcx to 
the IPS. 

Architecture - A structure tliat shows the elements and tlicir rclationsliip for a set of requirements or a s> stcm 
concept or both. 

ATC - Affordability through Commonality' Program 

BIW - Bath Iron Works 

CALS-GCO (Continuous Acquisition and Life Cycle Support- Government Concept of Operations): A document. 
Provides the Govenunent Concept of Operations (GCO) for data associated with the SC 21 Program in 
conformance with the basic strategy' of Continuous Acquisition and Life-Cycle Support (CALS). 

CDR - Critical Design Re\iew', re\icw' conducted to determine that the detailed design satisfies performance and 
engineering requirements of the de\ elopmcnt specification; to establish the detailed design compatibihty' 
among the item and other items of equipment, facilities, computer programs, and personnel; assesses 
producibility' and risk areas; and to re\icw' the preliminary' product specifications. 

CDRL - Contract Data Requirements List, Document used to order and require delivery* of data. Tells contractor 
what data to deli\er, when and how it will be accepted, where to look for instructions, etc. 

COEA - Cost and Operational Effectiveness Analysis, OBSOLETE, superceded by AoA. 

Concurrent Engineering - A sy stematic approach to the integrated, concurrent design of products and tlieir related 
processes, including manufacture and support. Tliis approach is intended to cause developers, from the 
beginning, to consider all elements of the system life cycle from requirements development through disposal, 
including cost, schedule and performance. 

Configuration item - An item that satisfies a documented set of requirements and is designated for separate 
configuration management to include any item required for logistic support or designated for separate 
procurement. 

Configuration management - For configuration items, (1) tlie identification and documentation of the configuration, 
(2) the control of changes to the items or their documentation, (3) configuration status accounting, and (4) the 
auditing to confirm that conformance to all requirements has been verified 

Cost As an Independent Variable - Methodologies to acquire and operate affordable DOD sy stems by setting 

aggressive, achievable cost objectives and managing acliievemcnt of these objectives. Cost objectives shall 
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be set to balanee mission needs with projeeted out-year resourees. taking into aecount antieipalcd proeess 
improvements in both DOD and defense industries. 

COTS - Commereial off the Shelf 

CPM - Critieal Path Method 

CVX - Next generation aireraft earner 

DAB - Defense Aequisition Board, the senior DOD aequisition review' board ehaired by the Under Seeretaiv' of 
Defense for Aequisition. The Viec Chairman of the Joint Chiefs of Staff is the Viee-Chair. Otlier members 
inelude tlie Deputy USD( Aequisition), Aequisition Exeeutives of the armed serv iees; the Direetor of Defense 
Researeh and Engineering; the Assistant Seeretaiy of Defense for Program Analysis and Evaluation; and the 
Comptroller of the DOD. 

DARC - Defense Aequisition Regulatory' Couneil, one of two eouneils authorized to generate ehanges to the Federal 
Aequisition Regulation (FAR). DARC members are from the Offiee of the Under Seeretaiy' of Defense for 
Aequisition. the DOD eomponents and NASA. 

DCP - Deeision Coordinating Paper. OBSOLETE, supereeded by IPS. 

DD-21 - Next eombatanl slup program after DDG-51, also designated SC-21 

DDG-51 Fliglii IIA - Added helieopter support and lengthened base design 

Defense Aequisition Exeeulive Summaiy' (DAES) - sunmiaiy' report of program progress presented to Offiee of 
Seeretaiy' of Defense (OSD) for review 

Design - noun : The result of designing. 

Design - verb: Arehiteeling and seleeling produets (ineluding proeesses) and eorresponding personnel manpower, 
skill levels, and speeialized traimng that salisfv' all requirements and deseribing lliem so tliat the produets ean 
be manufaetured or eoded, verified, deployed, operated, supported, and disposed of and so that the personnel 
ean be seleeted and trained. 

DMRS - Defense Mobilitv' Requirements Study 

DoD Direetive 5000.1 (Mareh 15, 1996) - States polieies and prineiples for all DoD aequisition programs and 

identifies the Department’s key aequisition offieials and forums, with supporting doeuments (DoD 5000. 2-R) 
it provides mandatorv' proeedures for major defense aequisition programs and major automated information 
system. 

DT&E - Development Test and Evaluation, T&E eondueted to measure progress, usually of 

eoinponents/subsystems. and to assist the engineering design and development proeess and verify attainment 
of teelmieal performanee speeifieations and objeetives. Usually eondueted under eontrolled or laboralorv’ 
eonditions. Can be eondueted before or after produetion begins. 

DWL - Designed Water Line 

DYNAMO - System Dmamies modeling software 

Engineering Change Proposal (ECP) - a proposal to the responsible aulhoritv’ reeommending that a ehange to an 
original item of equipment be eonsidered, and the design or engineering ehange be ineorporated into the 
artiele to modifr' , add to. delete or supersede original parts. 
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Federal Acquisition Reform Act (FARA) - cited as the Federal Aequisition Reform Aet of 1995, requires 

go\ emmcnt construction projects to follow a two phase contracting approach; phase 1 will define technical 
requirements, approaches and evaluation procedures (but not detailed design specifications or cost ceilings) 
for open contract competition: phase 2 will award a contract based on the evaluation procedures delineated in 
phase 1. 

Federal Acquisition Streamhning Act (FAS A) - cited as the "Federal Acquisition Streamlining Act of 1994", the act 
allows government agents to negotiate hmited contracts (by amount, duration and scope) without the 
requirements of open competition and contract bidding. 

Functional Configuration Audit (FCA) - tlic formal examination of functional characteristics test data for 

configuration item, prior to acceptance, to verify that the item has achieved the performance specified in its 
functional or allocated configuration identification. 

Functional analysis and allocation - The decomposition of each of the top-level functions to sub-functions to the 
point that each sub-function can be related to the elements of a physical hierarchy, the allocation of the top- 
le\ el performance requirements and design constraints to the functions and sub-functions, and the capture of 
the aggregation in a functional architecture. 

Functional architecture - The hierarchical arrangement of functions and their deeomposition to sub-functions and tlie 
allocation of the top level pcrfonnance requirements and design constraints to functions and sub-functions. 

Fmictional baseline - The initially approved documentation describing a s>'stcm's top level funetional and 

performance requirements and design constraints and all changes thereto. Tlie functional baseline can be 
changed only with Government approval. The functional baseline is usually initially approved near the end 
of the Program Definition and Risk Reduction Phase, as part of the procurement process for Engineering and 
Manufacturing Development. 

Hull, Mechanical & Electrical (HM&E) - The totality of non-payload (Upically combat systems) ship s> stems and 
components. 

HVAC - Heating, Ventilation and Air Conditioning 

Integrated Logistics Support (ILS) - A disciplined unified, and iterative approach to the management and technical 
acti\ities necessar/ to (1) integrate support eonsiderations into s> stem and component design: (2) develop 
support requirements that are consistently related to readiness objectives, to design, and to each other; 

(3) acquire the required support; and (4) provide the required support during the operational phase at 
minimum cost. 

Integrated Management Plan (IN4P) - A contractual description of the applicable documents, significant 

accomplisliments. accomplisliment criteria, events, and critical processes necessar>^ to satisfy all contraet 
requirements. The completion of each significant accomplishment is determined by measurable 
accomplisliment criteria. The significant accomplishments have a logical relationship to each other and, in 
subsets, lead up to events. Each Event is, in timi, complete when the significant accomplishments leading up 
to it are complete. The cntical processes are described by narratives that include Objectives, Governing 
Documentation, and an Approach. The LN4P includes an indexing scheme (sometimes called a single 
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numbering s>stem) that links each significant aeeomplislimcnt to the associated CWBS element, event, 
significant aceomplishment criteria, and tasks presented in the Integrated Master Schedule (IMS). The data in 
the IMP defines the neccssar\' aeeomplisliments for each event both for each IPX and for the contract as a 
whole. 

Integrated Master Schedule (IMS) - The schedule showing the time (calendar) relationship between significant 
aeeomplishmcnts, events, and the detailed tasks (or work packages) required to complete the contract. The 
FMS uses (and extends if nceessar>) the same indexing (or single numbering s> steni) as used in the Integrated 
Master Plan (IMP). 

Integrated Product and Process Development (IPPD) - A management teelinique tliat simultaneously integrates all 
essential acquisition activities through the use of multi-disciplinary^ Integrated Product or Process Teams 
(IPTs). Specifically defined in the DOD Guide to Integrated Product and Process Development, 5 Feb 96. 

Integrated Product Team (IPT) - Team composed of specialists from all applicable functional disciplines working 
together (1) to deliver products and processes that affordably meet all requirements at acceptable risk and 
(2) to enable decision makers to make the right decisions at the right time by timely aeliie\ cment of the 
significant accomplislnnents in the Integrated Master Plan (IMP). 

IPS - Integrated Program Summar\\ a DOD Component document prepared and submitted to the milestone decision 
authorit}^ in support of Milestone I, II. Ill and IV re\ iews. It provides an independent assessment of a 
program's status and readiness to proceed into the next phase of the acquisition eyele. 

Interface requirement - The fimctional and physical design constraints imposed on each other by two or more 
fimetions. items, or svstems or between a sv stem and a facility. Functional interfaces include signal, 
electrical, cleetroniagnetie, and software. Physical interfaces include keep-out volumes and mating surfaces 
and connections. 

Interface - The boundary’, physical or conceptual, between two or more functions. s> stems, or items or between a 
system and a facility at which interface requirements are set. 

IOC - Imtial Operational Capability', the first attainment of the minimum capability' to effectively employ a weapon, 
item or equipment, or sv stem of approved speeifie eharacteristies, and w hieh is manned or operated by an 
adequately trained, equipped, and supported military unit or force. 

JIT - Just In Time, a ‘‘pull" system, driv en by actual demand Goal is to produce or prov ide one part just-in-time for 
the next operation. Reduces stock inventones, but leaves no room for schedule error. As much a managerial 
pliilosophy as it is an inventory' system. 

LBP - Length between Perpendiculars - usually the Icngtli of the ship at the waterline 

Legacy system - A s> stem/subsv stem/component associated with or envisioned for a DOD application, that exists or 
ean be anticipated to exist in a time frame that supports its melusion as part of a design being developed to 
met a current requirement. 

LFT&E - Live Fire Test & Evaluation, surv ivability testing and lethality' testing required before full-seale 

production. Must be conducted (unless a waiver is approved by the USD(A)) on ACAT I and II programs 
for: 
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a. a covered s\stem (a vehicle, weapons platform, or conventional weapon sy stem designed to provide some 
degree of protection to the user in combat, 

b. a major munitions or missile program or 

c. a product improvement program that will significantly affect the survivability of a covered s>^stem. 

Life Cycle Cost (LCC) - Life cycle costs include all Research and Development, Procurement, and Operation and 
Support costs from program inception to disposal of the last associated end item. The minimum categories of 
cost, wliich shall be used to estimate life cycle cost, are as follows: 

Research and Development Costs : Includes all costs associated with conceptual/feasibility studies, basic 

research, adv anced research and development, engineering design, fabrication and test of engineering 
protot>pe models (hardware), and associated documentation. These costs are generally non-recurring. 
Procurement Costs : Includes all costs associated with the acquisition of systems/equipment (once the 
Research and Development has been completed). Tlie following subcategories apply: 

Construction Cost : Includes all facility construction, capital equipment and facility maintenance. 
Manufacturing Cost : Includes all recurring and non-recurring costs associated with the production and 
test of multiple quantities of prime systems/equipment. 

Non-Recurring Manufacturing Cost : Includes all fixed, non-recurring costs associated with the 

production and test of operational sv stems/equipment. such as manufacturing management, 
manufacturing engineering, initial factory' tooling and test equipment, qualiU' assurance, first 
article qualification test (reliability' test, maintainability demonstration, support equipment 
compatibility, technical data verification, personnel test and evaluation, interchangeability, and 
environmental test) and related support, production sampling tests and related support. 

Recurring Manufacturing Cost : Includes all recurring end item production costs such as fabrication, 
subassembly and assembly, matenal and inventory' control, inspection and test, and packaging 
and sliipping. Sustaining engineering support required on a recurring basis is also included. 
Initial Logistics SuptX)rt Costs : Includes operational test and support eqmpment, training equipment 
and spare/repair parts material costs. 

Operation and Support Costs : Includes all costs associated with operating and maintaining the sv stem after 

delivery. Tlie following subcategories apply. 

Mission Personnel : Tlie costs of all pay and allowances for military' personnel required operating the 
end item 

Unit Level Consumption : The cost of fuel, repair parts and supplies, depot-level repairables, training 
munitions and expendable stores, purchased services and the cost of temporarily assigned 
personnel. 

Inteniiediate Maintenance : The cost of maintenance and repair actions performed by tenders and 
shore-based inteniiediate maintenance activities. 

Depot Maintenance : Tlie cost of ship overhauls and the installation costs of perfomiing sliip 
modifications (fleet modernization). 
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Sustaining Support : The cost of centrally pro\ided material (equipment associated with ship 

modifications), sustaining engineering support, software maintenance and any other require 
sustaining support. 

Indirect Support ; The cost of system specific training, permanent change of station and medical care. 
System Phase-Out and Disposal . The cost of condemning or disposing of an item. 

LOA - Length over All - Total length of the ship 
LSI - Lean Ship Initiative 
Margin - Reserve for future growth 
MARITECH - Marine Systems Technolog>' 

MILSPEC - Militar}' Specifications 

Molecules - System Eh naniics Building Blocks generated by Jim Hines for Vensim and 15.875 
NAVSEA - Naval Sea Systems Command 
NAVSHPSSO - NAVSEA Shipbuilding Support Office 
Non-Developmental Item (NDI) - Any item that is 

(1) a\ ailable in the commercial marketplace or 

(2) previously developed and in use by a department or agency of the United States, a Stale or local 
Government, or a foreign Government w ith which the United States has a mutual defense cooperation 
agreement and tliat does not require umque upgrades or maintenance over its life-cycle to meet the 
current requirements. • 

In some cases NDI may be extended to include items that 

(a) have been developed but are not yet available in the commercial marketplace or in use by a Government 
entity or 

(b) require only minor modification or upgrade. 

Open s>'stem; A s\ stem architecture wluch uses a generally accepted set of industr\' standards to define s\ stem 
interfaces such tliat components or subsystems can be readily substituted or upgraded. 

Operating and support costs: see Life Cycle Cost 

OT&E - Operational Test and Evaluation, the field test, under realistic conditions, of any item (or key component) 
or w eapons, eqiupment, or munitions for the purpose of determining the effect i\'C ness and suitabilit}’ of the 
w eapons, equipment, or munitions for use in combat by typical mihtaiy' users; and the evaluation of the 
results of such tests. 

PC A - Physical Configuration Audit, physical examination to \ erif\ that the configuration item(s) “as built' 
conforms to the technical documentation wliich defines the item. Approval by the govermnent program 
office of the Cl product specification and satisfactor}' completion of tins audit establishes the product 
baseline. May be conducted on first full production or fist LRIP item. 

PDR - Preliminary Design Review; review' conducted to ascertain if the preliminaiy' design is to be committed to 
detailed design. Conducted for each configuration item to e\ aluate the progress, technical adequacy and risk 
resolution of the selected design approach, to detennine its compatibility w ith performance and engineering 
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requirements of the development speeifieation, and to establish the existenee and eompatibility of the 
physieal and fimetional interfaees among the item and other items of equipment, faeilities, eomputer 
programs and personnel. 

PERT - Probabilistie Evaluation and Review Teelinique 

Pliase - Period of time that eorresponds to one of the four primaiy^ phases of engineering and design. The phases 

inelude Coneept Design Phase, Preliminary Design Phase, Contraet Design Phase and Detailed Design Phase. 

Physical architecture - The physical hierarchy and the functional requirements and design constraints for each 

element in the hierarchy. It can be viewed as an intennediate step between the functional architecture and the 
physical hierarchy, on the one hand and the allocated baseline, on the other hand. 

Procurement cost - see Life Cycle Cost 

Product hierarchy, physical hierarchy - Tlie liierarchical arrangement of products, processes, personnel skill levels, 
and manpower levels that satisfy the functional baseline. The top entry in the hierarchy is the s> stem. The 
hierarchy extends to include all components and computer software units necessaiy^ to satisfy the functional 
baseline whether deliverable or not. It includes the prime operational hardware and software. Contractor- 
supplied support equipment, Government-in\’entor>^ support equipment, technical manuals, training programs 
for both Government and Contractor persoimel, Govermnent persoimel skill and manpower levels, spare parts 
requirements, and factoiy' support equipment and tooling which collectively result in the s\ stem that satisfies 
the fimetional baseline. 

PRR - Production Readiness Review, a formal examination of a program to determine if the design is read\^ for 
production, production engineering problems ha\ e been resolved, and the producer has accomplished 
adequate planning for the production phase. 

PWBS - Product Work Breakdown Structure 

QA - Quality Assurance 

Requirements: Characteristics, attributes, or distinguisiiing features that a sy stem or sy stem element must have 
w ithin a stated environment or set of conditions in order to meet an operational need and comply w ith 
applicable policy and practices. 

Risk management - A documented process for the prospectn e (looking ahead) and recurring identification of what 
can go wrong, assigning a level of risk (e.g., Higli. Moderate, Low) to each risk, and planning and 
implementing mitigation steps for each commensurate with the le\ el of risk. 

Risk - A measure of the uncertainty^ of attaining a goal, objective, or requirement and the consequences of not 
attaining it. Tlic uncertainty' is the result of one or more undesirable Ev ents that could occur during the 
system life cycle for which insufficient resources and time are programmed to overcome them. The 
consequences are inability to satisfy the operational military’ need and exceeding the programmed budget and 
directed schedule. 

RRF - Ready Reserv e Force 

SA' AR - Corvette sized combatant built by Ingalls for Israeli Navy. 

SC-21 - Next combatant ship program after DDG-5 1 , also designated DD-2 1 . 
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Scaleable - An attribute of design: develop designs, architectures, systems and transitions teclmologies that era 
adaptable across a range of end items (such as ship classes). 

SCP - System Concept Paper, OBSOLETE, has been superceded by Integrated Program Summary (IPS) 

Selected Acquisition Report (SAR) - report of program progress presented to congress for budgetarv^ oversight. 

SEMP - System Engineering Management Plan, includes plans for verification, risk alleviation, analyses and 
simulation of the system requirements. 

Ship Production Model - A virtual representation of a particular sliip being built at a shipyard 

Shipbuild - New project planning and progress tracking software wliich w ill use some elements of System Dynamics 

SFR - System Functional Review 

SHP - Shaft Horse Power 

Signature - Any attribute of any object by w hich a sensor can detect, locate and/or classify that object. 

Significant accomplishment criteria - Specific, measurable conditions that must be satisfactorily demonstrated 

before a significant accomplishment listed in an Integrated Master Plan (IMP) is complete and before work 
dependent on the accomplishment can proceed. 

Significant accomplislmient - A specified step or result lliat indicates a level of progress toward completing an event 
and, in turn, meeting the objectives and requirements of the contract. 

Simulation - The process of conducting experiments with a model (an abstraction or simplification) of an item 
and/or part or all of its operating enviromneiit for tlie purpose of assessing its behavior under selected 
conditions or of evaluating various strategies for its operation within the limits imposed by developmental or 
operational criteria. Simulation may include the use of analog or digital devices, laboratorv’ models, or ’’test 
bed" sites. Simulations are usually programmed for solution on a computer; however, in the broadest sense, 
militarv' exercises and war games are also simulations. 

Specification tree - The hierarchical depiction of all the specifications needed to formally control the dev elopment, 
procurement, manufacture, integration, verification, and/or reprocurement during any part of the life cycle. 

SSR - Systems Requirement Review, conducted to ascertain progress in defining sv'slem technical requirements. 

Determines tlie direction and progress of the sv stems engineering effort and the degree of convergence upon a 
balanced and complete configuration. Normally held during the CE/D phase, may be repeated after start of 
D/V to clarify' the contractor's understanding of redefincd/new' user requirements. 

STAR - Sy stem Threat Assessment Report. Documents the authoritative tlireat assessment tailored for and focused 
on a particular US defense acquisition program. Prepared by the Serv ice intelligence agency and validated by 
DIA at milestones 1, II, III & IV. Applicable to all tlireat driven defense acquisition programs. Must be 
system specific threat oriented. 

Stealth - Ability to evade radar 

Supportabilify - The degree to which planned logistics support (including sy stem design; test, measurement, and 
diagnostic equipment: spares and repair parts; teclmical data: support and facilities, transportation 
requirements: training, manpovyer: and software support) alloyv meeting sy stem availabihfy and yy artime 
usage requirements. 
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SUPSHIP - Supervisor of Shipbuilding 

Surv ivabilit>' - The capability of a sv stem to avoid or withstand man-made hostile environments without suffering an 
abortive impairment of its ability' to accomplish its designated mission. 

Sustainability - To prolong performance over a period of time. 

System Dynamics - Methodolog}' used to examine complex problems with non-linear relationships and feedback 

Sv'stem engineering - A process, applied iteratively throughout the System life cycle to translate stated objectives 
into design requirements, providing an integrated solution consisting of people, products and processes with 
the capability to satisty’ the customer needs. 

Sv stem - The entity' to be designed as defined by the work breakdown structure. The entity for DD 21 Systems 
includes the ship and the infrastructure that supports ship operation, maintenance, readiness, etc. 

Technical Performance Measure (TPM) - A parameter that is related to progress toward meeting tlie program or 
contract functional requirements or goals and is assessed periodically and at certain events to estimate the 
degree to which the final value will meet the anticipated or required level. 

TEMP - Test and Evaluation Master Plan, an overall test and evaluation plan, designed to identity' and integrate 

objectives, responsibihties, resources, and schedules for all test and evaluation to be accomplished prior to the 
subsequent key decision points. Prepared, as early as possible in the acquisition process, it is updated as 
development progresses. 

Total Ownership Costs (TOC) - All the components of traditional Life Cycle Cost plus so-called linked, indirect 
costs (the fraction of supporting facilities/systems developed to support the given sv’stem.) 

Traceability' - The ability to relate an element of the functional baseline, functional architecture, physical hierarchy, 
allocated baseline, design baseline, and product baseline (or their representation in the decision data base) to 
any other element to which it has a master-subordinate (or parent-cliild) relationship. 

Trade studies An objectiv e comparison with respect to performance, cost, schedule, risk, and all other reasonable 
criteria of all realistic alternative requirements: architectures: baselines; or design, verification, 
manufactiuing, deplov ment, training, operations, support, or disposal approaches. 

Upgrade - A change from prev iously delivered items because of obsolescence of a part: a change in the militarv' 
need or tlircat; an operational, supportability, or training deficiency is identified: the s\ stem life must be 
e.xtended: a change in the law occurs: or an unsafe condition is detected. 

Vensim - System Dynamics modeling software 

WIP - Work In Progress 

Work Breakdown Structure (WBS) - A product-oriented hierarcliical tree composed of the hardware, software, 
serv ices (including cross-product tasks such as systems engineering), data, and facilities that encompass all 
work to be carried out under the program or contract along with a dictionarv' of the entries in the tree. The 
WBS for the entire program is called the Program or Project WBS (PWBS). The WBS for the work under the 
contract is called tlie Contract WBS (CWBS) and is prepared in accordance witli the contract. 

Zones - Defines w hat functions are carried out in this portion of the ship e g. Machinety. Living, Storage 
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8.4 Design Task, Discipline and Duration Resources 

A vast quantiU' of material was anah^ed to pro\ide both general and specific data supporting the naval ship 

design process model. To specifically callout these references at each instance of assessment (Chapters 4 and 5) 

would be inappropriate. Therefore, the following list and brief descriptions of reference materials will be given to 

provide the reader with knowledge of those resources: 

• And\^ Summers, Contract Design Historv^ for the Guided Missile Destroyer (DDG 31 Class) , Naval Sea Systems 
Command, Washington DC, June 1987. Contains contract design schedules, hstings of resources (budgetaiy^ 
and personnel), listings of design products, descriptions of design processes and technical results. 

• And)’ Summers, DDG-51 Guided Missile Destroyer Preliminary Design History , Naval Sea Systems Command, 
Washington DC, June 1984. Contains preliminary’ design schedules, listings of resources (budgetaiy^ and 
personnel), listings of design products, descriptions of design processes and technical results. 

• Bany^ Tibbitts, “Wliy Ships are Different’', John J. McMullen Assoc., 1991. General description of design 
spiral elements and practical aspects of nav al sy stem engineering. 

• Brown and Welsh, “FF13A Ship Design Math Model”, Massachusetts Institute of Technology’ course 
Applications of Naval Sy stem Design, Fall 1996. A MathCAD model using parametrics to develop a balanced 
surface combatant design, model demonstrates physical and empirical relationships relative to the design 
process. 

• C.R. Lloyd. Design Processes for the AEGIS Destroyer Program . Presentation by Bath Iron Works (BIW), 
November 18, 1997. Discussion of detailed design process, team structure and design products supporting the 
lead ship and manufacturing design of the DDG-5 1 class surface combatant. 

• Doug Hilton, “PME IDEF Model”, Nav al Sea Sy stems Conmiand, September 13, 1994. IDEF description of 
concept and preliminary^ design applicable to naval design using the Product Model Extension (PME) program. 

• Edward Lewis, Pnnciples of Naval Architecture , Society of Naval Architects and Marine Engineers, Jersey 
City’, NJ, 1988. Detailed descriptions of all aspects of naval ship design including hydrostatics, hydrodynamics, 
structural analysis and design integration. 

• Gale and Scott, “Early Stage Ship Design Seminar”, Society of Naval Architects and Marine Engineers, 

October 1995. Discussion of the elements of the design spiral for concept design and the basic relationships 
among those elements. 

• Greg Diggs, MAAST (Maritech Agile Shipbuilding Toolkit), Advanced Marine Enterprises Inc., March 26, 
1997, lutp;//wx\w.ad \ ma r.com/fra inew ork/splash.htm. IDEF descriptions of complete design process for a 
generic “commercial” ship design. 

• John Dalton. Implementation of Mandatory Procedures for Major and Non-Major Defense Acquisition 
Programs and Major and Non-Major Information Technology Acquisition Programs (SECNAVINST 5000 2B) . 
Department of the Navy', Washington DC, December 6, 1996. Programmatic requirements relative to all phases 
of design process including listing of those design and risk assessment products required by' law, statute and 
direction. 
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• John Dalton. Program Decision Process (SECNAVINST 5420. 188E) . Department of the Navy, Washington 
DC, October 3 1, 1995. Programmatic process description of lliose design products that must be presented at 
each milestone authorization. 

• Karaszevvski and Wade, Infrastructure Studv* in Shipbuilding: Report on Initial Findings Part 2, IDEFo 
Diagrams and Glossary, David Taylor Research Center. Bethesda, MA, Januarv' 3, 1991. IDEF descriptions of 
complete design process for a generic ‘’commercial” ship design. 

• Mahoney, Welsh and Moton ”13.412 DD13A Feasibilitv' Design Requirements”, Massachusetts Institute of 
Technologv' course Apphcations of Naval System Design, Fall 1997. Listing of design products required for 
concept and feasibility' assessment of a surface combatant design. 

• Myron Ricketts, Manual for Naval Surface Ship Design Technical Practices . Naval Sea Systems Command, 
Washington DC, 1980. Detailed descriptions of all design phases, all design products, and design inter- 
relationships necessaiy to enable individual NAVSEA engineers understand the impacts of design decisions on 
other design elements. 

• Naval Surface Warfare Center Carderock Division, “Getting Started & Tutorials: Adv anced Surface Ship 
Evaluation Tool (ASSET) Family of Ship Design Synthesis Programs", September 30, 1997. Description of the 
ASSET modules, formulations and sy ntliesis structure. 

• RADM Roger B. Home, “Concept to Commissioning. Improv ing the Ship Design. Acquisition and 
Construction Process: Strategic Plan”, Naval Sea Systems Command. Wasliington, DC, June 1991. Detailed 
analy sis of nav al ship design process including statistical assessment of design timelines and costs, interviews 
and suggestions from design participants, and design organization stnictures. 

• Ron Ni.\, “T-AG9X Preliminary/Contract Design Estimates”, Nav al Sea Systems Command, January’ 16. 1987. 
Listing of design products, timelines and iterations (presented by design discipline and sub-discipline) estimated 
for an aaxiliary’ ship. 

• Scott Ripley, “Pre-Contract Product Development-Process Flow Chart”, Newport News Shipbuilding, 

December 1 1. 1996. IDEF diagram for all processes (engineering, cost, programmatic, legal, etc.) related to the 
development of an aircraft carrier. 

• Ship Design Group, Ship Design Project Histories: Volume I. II and HI . Naval Sea Systems Command. 
September 1978, May 1986 and August 1996. Complete descriptions of concept tliroiigh contract design for all 
naval ship designs developed from 19^0 through 1996. Includes manpower allocation, design disciplines, costs, 
sliip descriptions and timelines. 

• Storch, Hammon. Bunch and Moore, Ship Production , Society of Naval Architects and Mamie Engineers. 

Jersey City, NJ, 1995. Generic description of design products, design organization and production 
considerations relativ e to general ship design. 
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8.5 Baseline DDG-51 Task and Productivity Levels 

The following data has been extrapolated from the references in Chapter 8.4 and was used to calibrate the 



Naval Ship Design Process Model. 



Node 


Task Element 


Average ManMonths Per Task (Adjusted for DDG-61 Program) 


Concept 


Preliminary 


Contract 


Detailed 


Ail 


Plans 


Construct 


Program atic 


Program Management Tasks 


0 63 


118 


11.37 


9 65 


11 41 


6 85 


Requirements & Assessment 


0 21 


0 38 


5 86 


4 96 


5 84 


3 45 


Risk Mitigation & Coordnaticn 


007 


038 


3 96 


3 22 


3 90 


2.30 


Systems Engineering 


Logsbes and Reliability 
Engineering 


1 02 


8 24 


11 72 


1681 


20 35 


11 63 


Desigi Integ^tion & 
Specificstions 


6 61 


7 36 


15 94 


15.87 


17 93 


12 74 


Producibility and Production 
Engineering 


255 


21 28 


11 75 


17,63 


21.35 


1491 


Performance-Requirements 

Assessmoit 


3 36 


5 57 


6 20 


7 12 


8 62 


6 18 


Manning 


1 69 


201 


2 06 


3 93 


4 76 


2 89 


Hull Engineering 


Hull Geometry 


1 97 


5 57 


1 97 


3.16 


3 82 


3 30 


Vi/ogit. Hull SubdMsicn & 
Hydrostatic Design 


1 96 


5 57 


0 19 


0 63 


0 76 


1 82 


Hydrodynamics-Resistance 


2 55 


5 57 


8 82 


11 35 


13.51 


8 36 


Hydrodynamics- Seakeeping 


2.55 


557 


8 82 


11.35 


13 51 


8 36 


H ydrodyn amic s-Maneuvenng, 
Appendage & Propeller Desigi 


2 55 


5 57 


1 26 


1 01 


1 22 


232 


Strvictures-Staic and Dynamic 
Design 


0 61 


5 57 


1 25 


1 19 


1 44 


201 


Space and Arrangements 


1,27 


0,15 


2 29 


2.02 


220 


1 59 


Machinery Systems 
Engineehng 


Mach in ay Systems Design and 
Integr^icn 


357 


5 86 


1.75 


5 03 


5 93 


4.43 


Propulsion Systems 


0 77 


0 62 


1.38 


1.69 


2 05 


1 30 


Electneal Systems 


0 77 


0 62 


1 38 


1 69 


2 05 


1 30 


Auxiliary and Support Systems 


1,30 


0 84 


5.42 


5.06 


6,13 


3.75 


Deck, Handling and Aircraft 
Support Systems 


1,28 


1 47 


0 30 


1 57 


1.90 


1 30 


Mission Systems 
Engineehng 


Mission Systems Selection, 
Design and Integ^tion 


3 56 


1,94 


1 81 


3 70 


4 48 


3 10 


Topside Design and Integration 


13 02 


1 24 


2 60 


6.26 


7 58 


6 14 


Cost 


Cost Estimates & Analysis 


061 


1 02 


5 29 


4 23 


5.13 


3 26 


Totals and Averages 


2 37 


4 07 


4 93 


6 05 


7 21 


4 93 
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Analysis and Approval Periods (workdays) 






Average for 45 Programs from CNA Study 




CG-47 


t DEX5-51 


Node 


Task Element 


NAVSEA 


PMO 


Review/ Approval Chain 


Review/ Approval Chain 


o 


Proyam Maiagement T asks 


36 


42 5 


46.3 






1 

a 


Requiremerts & Assessment 


64 


53 0 


76 3 


1000 


24 0 


& 


Risk Million & Coordination 


75 


1150 


1400 






a 


Logistics and Reh ability 
Engneenng 












■c 

c 

c 

c 

a 

c 

lU 


Design Integration & 
S pec ifi cations 












Produ ability and Producbon 
Engneenng 


05 


15 0 


50.0 






£ 

c 

v> 


Performance-Requirements 

Assessment 














Manning 














Hull Geometry 














Weight. Hull Suba^sion & 
Hydrostatic Design 












at 

c 

'C 


Hyct-odjn amic s- R esi s tanc e 












• 

o 

c 

O) 


H y rtod)fiamic s- Seakeepi ng 












c 

U1 

3 

X 


H y cfod>Ti amic s- Man euvenn g. 
Appendage & Propeller Design 














Structures-Static and Dynamic 
Design 














Space and Arrangements 












ifi 

£ 


Machinery Systems Design and 
Integation 












£ a> 

t i 


Propulsion Systems 












vt c 
^ c 


Electncal Systems 












If 

u 


Auxiliary and Support Systems 












s 


Deck, Handling and Aircraft 
Support Systems 












v> 

1 ’ 
^ : 


Mission Systems Selection, 
Design and Integation 












c S 
.9 O’ 
i;; 
s 


Topside Design and Integ-ation 












Cost 


Cost Estimates & Analysis 


94 


100 


35 0 






Totals and Averaaes 


52 


31 7 


57 5 


33 3 


80 
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Average Number of Design Tasks 


1 Detailed I 


Total 


55 


'T 


52 


CO 


<J> 


<M 


20 


<£) 


CD 


80 


CO 


CO 




<N 

r-- 




47 


<N 

CO 


CM 

CO 


56 


28 


O 


20 


CM 


r-- 


Production 1 




o 


CO 


(N 




CO 


in 




'T 


o 

CM 


(M 


CM 




CO 


\oz 


CM 


CO 


CO 






o 


in 


CD 


CM 

o 

CM 


IZonal 1 




o> 


CO 


<N 


If) 


CO 


m 


'T 


'T 


20 


CM 


CM 




CO 


o 

<N 


CM 


CO 


CO 






o 


in 


CD 


o 

CN 


Transition I 


'a' 


CO 


CO 


rsi 


If) 




m 






20 


CM 


CN 




CO 


r-- 


CM 


CO 


CO 






o 


in 


CD 




1 Functional I 


n 


CO 


CO 


CM 


'sr 


CO 


m 






o 

CM 


CM 


CN 




CO 






CO 


CO 






o 


in 


CD 




Contract 


CD 


CO 


CO 


CM 




CM 


m 




■O' 


20 


CN 


CN 




CO 


CD 


o> 


CO 


CO 


'T 




o 


in 


CD 


o> 


Preliminary 


o 


CO 


CO 


CN 


CO 


CM 


in 




'sr 


O) 


CM 






in 


CD 


00 


r-- 




CM 




a> 


in 








Concept 


CO 


CO 


(N 


CM 






■O' 


CM 




CD 


CM 




CM 


n-. 


in 


CO 


CM 


CM 


CM 




cn 


<N 


CO 


CO 

oo 


Node - 
Task 


- 


(N 




- 


(M 


CO 




in 


- 


CM 


CO 


'T 


in 


CD 


b- 


- 


CM 


CO 




in 


- 


CM 


- 




< 


< 


< 


CD 


CD 


CD 


CD 


CD 


O 


O 


O 


o 


O 


O 


o 


D 


Q 


Q 


Q 


Q 


m 


liJ 


LL 




Task Element 


Program Management Tasks 


Requirements & Assessment 


Risk Mlfcgaticn & 
Coordinabon 


Logistics and Reliability 
Engineenng 


Desiyi Integration & 
Speaficafaons 


Producibitity and Production 
Engineenng 


Performance-Requirements 

Assessment 


Manning | 


Hull Geometry 


Waght. Hull Subdivision & 
Hydrostatic Desiyi 


Hydrod ynam 1 cs- R esi stance 


Hydrodynamics-Seakeeping 


Hydrodynamics-Maneuvering, 
Appendage & Propdler 
Design 


Structures- Static and 
Dynamic Desigi 


1 space and Arrangements | 


Machinery Systems Desi^ 
and Integration 


Propulsion Systems 


Electrical Systems ] 


Au)oIiary and Support 
1 Systems 


Deck, Handing and Aircraft 
Support Systems 


Mission Systems Selection, 
Desigi and Integration 


Topside Design and 
Integration 


Cost Estimates & Analysis 


1 Total and Averages 


Node 


3 |)eiui 2 j 6 oJcJ 


Buu 90 uiBu 3 siuaisAs 


6uuaauiBu3 |]nH 


BuuaouiBu^ 
sujatsAs Aiauiqoeku 


BuuaauiBus 
siueis/Cs uojssivu 


isoo 



8.6 Programmatic Task Development and Processing 
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MNS REVIEW, VALIDATION, AND APPROVAL PROCESS 
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Acquisition Program Baseline (APB) OPNAV Processing Procedures 




Figure 63 Acquisition Program Baseline (APB) Processing Procedures**^ 



Ibid. 
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ORD REVIEW, VALIDATION. AND APPROVAL PROCESS 



ASreSSMENTS 

(N31) 



STEP * 



MiLESTOhE 
DEOSION 
4UTHC)RITY 
rNOTE S) 



JPD=jOINT POTENTI/M. 
DESIGNATOR 
^OINT 

-JOINT INTEREST 
iNDEPENOCN^ 



SPONSOR 

-PREPARE DRATTORD BASED ON 
JK3A ANALYSIS 
ADMINSTER /track 
-ASSIGN SPONSOR priority 
-ENSURE PERFORMANCE 
PATA^CTERSfilEET MISSION NEED 



Jinitiate .aoa anal '/sis] 



SERVICES JPD RE MEW C91 , SI , 
33 AND OTHE RS AS TOPICS 

relate 



USA. USAf . USMC 
(SERVICE ORD1 



SERVICE ORD 



STEP 3 



(NOTe 2) 



SPONSOR 

•CONSOUDATE COMMENTS 
-PREPARE SMOOTH ORD 
SION « FORWARD 

-FOR POTENTIAL ACAT ID COORDINATE 
VMTH NmOFCR JROC BRIEF 
R38TNOTE 31 



iNiTi>:lREMEvVA#TD COMMENT 

NOS1 

N095 



N83- (ONCs REMP^Af) 



N81 REMEM/ANO COMMENT 
-ADMINISTER AND TRACK 
-PRIORITIZE NEED 

-FORWAROORD TO JROC JND OTHER SERVICES 
FORlNTERCPERAaJTYEVALUATION AND 
JONT assessment 
-STAFF SERVCE ORDsFOR OPNAVJPD 
ASSESSMEN-^ <NCTE 21 



JOINT STAFF FOR 

NTEROPERABILITYCERTIFICATION 



NOTE 

C) COPT PBOMCED FOR INFORWtftTlON 
CO FOROftDgMWI-m JONT, HTI5IESTMNS 
OR NO PROCSPOING MNS-SS5V1C6 
REASSESS JOINT P0T£MTP1./VPUCAI;0N 
3 M8 CHAR RESOURCES REOUIRBWEMTS 
ReAEW90Aft0(fOF) f*ETSASREOURED 
(0 SB* AHD C*l SYSTW Rp_AIH» PR0GR<«S 
a U3WC PROORflMSWITKUSN RSC/N. 
SPOHSOPSHIF 

flx:Ar It. Ill IV- Mj eiooRSE tehn acwc fob 

APPRO V*l 

A£AT I • MS OIDOBSe. TNFM Aa"C FOR 
APPSOMM 

®1 "lL6STONeOECISlOMAUTHORITyfMt>!) 
•USOVUTT TOR ACAT 10 
. ASH(Br»«iFORA£ATIC. I 
STSC0‘VPa3/nRFN FOR ACAT II. V 
(7) CNO'^TV.IOAIESAMDRFFROVEaFOB MAVT. 
A«0 FOR JROC WTHEN 3E160AT£0 



STEP S 

SPONSOR 

-COLLECT ENDORSEMENTS 8 
F0WA8D TON81 
FORWiT^D DRAFT APB TO N01 



(PROVIDE AOVAJ^CE COPYTONSIO) 




FINAL FLAO LEVEL 6IC>ORSEMENT 

N031 

N096 



STEPS 



STEP 10 



SPONSOR 

FORWARD APPROVeO ACAT 1C, II 
III.IVORDMDACVOFE 6; 
AfTPRSFRI-AL'/TD 



-ENDORSE ACAT I ORD 
FWO RECOMMENDATIONS TO CNO 
■REMEW JROCBR’EF 



► NS1Q 
_ SERIALIZE AND 
ISSUE 



CNO 

VCNO VAUDATE i 
fiPORO'J^ 
ACAT 1C, D 

Icffg fflOTS ^1 



JROC 

VALIDATE KEY 
PERfOPWANCE 
PARAMETERS 
EXTRACTED 
n?CM ACATID CRD 



-H jso ,A^rj j 



Figure 64 Operational Requirements Document (ORD) Review, Validation and Approval Process 
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8.7 Naval Ship Design Process Model 



The following formulations arc show n in the format of Vensim code. For electronic copies of the formulatioru 
contact the author at tomkimlav@sprintmail.com. 



Contracted Assign Rate [Phase, Discipline] = 

Current Phase [Phase] *MIN(Conlractor New' Assignments[Phasc,Discipline]/Conlractor Assign Period\ 
[Phase], Contractors Available [Phase. Discipline 
]/Contractor Assign Period[Phase]) 

~ Manpower/Month 



Adjust Rate[Phase]= 

0.4,0.3,0.3,1. 1,0.7 

Dimensionless 



Adjusted Desired Manpower[Phase,Discipline]= 

Desired Manpower[Phase,Discipline]*Effect of Schedule Gap on Desired Manpower [Phase, \ 
Discipline] 

Manpower 



Effect of Schedule Gap on 0\ ertimc[Phase.Discipline]= 

Effect of Schedule Gap on Ov ertime f(Schedulc Gap[Phase,Discipline]) 
~ Dimensionless 



Net Contractors= 

SUM(Contractors Phase[Phasc!]) 
~ Manpower 



Effective E\pcrienced[Phase,Discipline]= 

Contractor Experienced[Phase,Disciplinc]*Overtime[Phase, Discipline] 
Manpower 

Experienced Contractor times assigned overtime 



Maximum Overtime= 

1.75 

~ Dimensionless 

~ Maximum monthly overtime that may be assigned of personnel 



Phase Task Change [Phase,EHscipline]= 

Rescope Rate[Phase, Discipline] 

~ Tasks/Month 

I 

Effect of Approval Phase on Desired Manpower[Phase]= 

Effect of Approv al Phase on Desired Manpower f( Approval Phase[Phase]) 
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I 



Dimensionless 



Phase Tasks[Phase.Discipline]= INTEG ( 

Phase Task Change[Phase,Discipline]. 

Initial Tasks[Phase, Discipline]) 
~ Tasks 



NAVSEA Assign Rate[Phase,DiscipUne]= 

Current Phase[Phase]*NnN(NAVSEA New AssignnientsfPhase, Discipline j/NAVSEA Assign Period\ 
,NAVSEA Available[Phase.Discipline]/NAVSEA Assign Period 

) 

Manpower/Month 



Rescope Rate[Phase,Discipline]= 

Current Phase[Phase]*Rescope Fractioii[Phase]*MAX(0,Input)*Initial Tasks[Phase.Discipline\ 
]/Approval Period[Phase] 

~ Tasks/Month 

~ The rate of design rescope by the DoN/DoD is indicator tliat the pliase \ 
impacted by rescope is the current phase (equals 1) times a random \ 
generation of desired change introduction (input) times the a fraction of \ 
the baseline (initial) tasks im olved in the rescope over the time \ 
required to introduce rescope (a period concurrent with the approval \ 
period) 



Net ProdiictiviU' Rate[Phase,Discipline]= 

Adjust Rate[Pliase]*Avg Design Rate[Phase,Discipline]*EffectOfFatigueOnProducti\ity[Phase\ 
,Disciphne]*Effect01^cheduleGapOnProductivity' 

[Phase, Discipline] ^Effect of Personnel Level on Product ivit> [Phase. Discipline] 
Tasks/(Manpower*Montli) 



Contractor New Released[Phase,Discipline]= 

IF THEN ELSE(Current Phase[Phase]=0. Contractor New [Phase.Discipline]/Contractor Release Penod\ 
,MIN(Contractor New Desired Release[Phase,Discipline]/Contractor Release PeriodContractor 

New'\ 

[Phase,Discipline]/Contractor Release Period)) 

Manpower/^Ionth 



Effect of NAVSEA Percent[Phase,Discipline]= 

Effect of NAVSEA Percent f(NAVSEA Percentage[Phase]/NAVSEA Participation Desired Percentage\ 
[Phase.Discipline]) 

~ Dimensionless 



NAVSEA New^ Release Rate[Phase,Discipline]= 

IF THEN ELSE(Current Phase[Phase]=0, NAVSEA New [Phase.Discipline]/NAVSEA Release Period\ 
,MIN(NAVSEA New^ Desired Releasephase,Discipline]/NAVSEA Release Period,NAVSEA 

New[\ 

Phase,Discipline]/NAVSEA Release Period)) 

Manpower/Monlh 



159 



Release of new project personnel is the minimum of the desired release and \ 
the release constraint (manning over time required to release personnel) 



Desired Duration[Phase]= 
18,8,10,16,6 
-- Montli 



Avg Design Rate[Concept,Discipline]= 

1.58, 4.8, 15.36, 0.98, 0.15, 0.39, 0.3, 0.59, 0.51, 0.51, 0.39, 0.39, 0.39, 1.64, 0.79\ 
,0.28, 1.3, 1.3,0.77, 0.78, 0.28 
, 0.08, 1.64 H 

Avg Design Rate[Prehminar> , Discipline] = 

0.85, 2.63, 2.63, 0. 12, 0. 14, 0.05, 0.18, 0.5, 0. 18, 0. 18, 0. 18, 0. 18, 0. 18, 0. 18, 6.83\ 
,0.17, 1.62, 1.62. 1.19, 0.68, 

0.52, 0.8, 0.98 H 

Avg Design Rate[Contract,Discipline]= 

0.09, 0. 17, 0.25, 0.09, 0.06, 0.09, 0. 16, 0.49, 0.5 1, 5. 15, 0. 1 1, 0. 1 1. 0.8, 0.8, 0.44\ 

, 0.57, 0.72, 0.72, 0.18, 3.35, 0.55 

,0.38, 0.19 H 

Avg Design RatefLead Ship, Discipline] = 

0.1, 0.2, 0.31, 0.06, 0.06, 0.06, 0.14, 0.25, 0.32, 1.6, 0.09, 0.09, 0.99, 0.84, 0.5\ 

, 0.2, 0.59, 0.59, 0.2, 0.64, 0.27, 



0.16, 0.24 H 

Avg Design Rate[Manufacturing,Discipline]= 

0.09, 0.17, 0.26, 0.05, 0.06, 0.05, 0.12, 0.21, 0.26, 1.32. 0.07, 0.07, 0.82, 0.69, \ 
0.45,0. 17, 0..49, 0.49, 0.16, 0.53, 

0.22,0.13, 0.2 

-- Tasks/(Month*Manpower) 



Baseline Desired Manning[Phase,Discipline]= 

Imtial Tasks[Phase,Disciphne]/(Avg Design Ratc[Phase,Discipline]*DesiredDuration[\ 
Phase]) 

~ Manpower 

- Baseline Maiming Requirement is the Number of Tasks over the tasks per man \ 
required to meet the desired schedule 



Effect of Schedule Gap on Overtime f( 

[(0,0)-(10,2)],(0.1),(l,l),(2,l),(10,2)) 

Dimensionless 

-- For schedule gap of 1 or less\!\!\! 



Initial Schedule Projection[Concept]= 

Desired Duration[Concept] ~| 

Initial Schedule ProJection[PreIiminar\]= 

Desired Duration[Concept]+Desired Duration[Preliminar> ] — | 

Initial Schedule Projection[Contract]= 

Desired Duration[Concept]+Desired Duration[Preliminaiv']+Desired Duration[Contract] 

Initial Schedule Projection[Lead Ship]= 

Desired Duration[Concept]+Desired Duration[Preliminar> ]+Desired Duration[Contract]+Desired Duration\ 
[Lead Ship] 
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Initial Schedi^le Projection[Manufacturing]= 

Desired Duration[Concept]+Desired Duration[Preliminar\]+Desired Duration[Contract]+Desired Duration\ 
[Lead Sliip]+Desired Duration [Manufacturing] 

~ Month 



Net Desired Manpower^ 

SUM(Desired Manpower Phase [Phase!]) 
~ Manpower 



NAVSEA Participation Adjusted Percentage[Phase,Discipline]= 

NAVSEA Participation Desired Percentage[Phase,Discipline]*Effect of NAVSEA Percent [Phase\ 
.Discipline] 

Dimensionless 

~ The desired manning level of NAVSEA relative to Contractors 



NAVSEA Participation Desired Percentage [Phase.Discipline]= 

MIN(NAVSEA Participation Nominal Percentage[Phase],NAVSEA Participation Nominal Percentage\ 
[Phase] *Effect of Approval Phase on NAVSEA Percent 
[Phase] *Effect of Available Budget on NAVSEA Percent[Phase]) 

-- Dimensionless 



Total Contractors Assigned[Phase]= 

(SUM(Effective Experienced[Phase,Discipline!])+SUM(Effective New[Phase.Discipline!])\ 
)*Current Contract Fee[Phase] 

~ Manpower 

The total contractors assigned as a cost is tlie sum of current contractors \ 
times tlie additional percentage charged to current contracts (10% overhead \ 
fee) 



NAVSEA Percentage[Phase]= 

NAVSEA Phase[Phasel/MAX( 1, NAVSEA Phase [Phase] +Contractors Phase[Phase]) 
~ Dimensionless 



NAVSEA Experienced Release Rate[Phase,Discipline]= 

IF THEN ELSE(Current Phase[Phase]=0,NAVSEA Experienced[Phase,Discipline]/NAVSEA Release 

Period\ 

.MIN(NAVSEA Exp Desired Release[Phase.Discipline]/NAVSEA Release Period,NAVSEA 

Experienced\ 

[Phase.Discipline 
]/NAVSEA Release Period)) 

~ ManpowerMonth 

~ Release of experienced persoimel is the minimum of the desired release and \ 
tlie release constraint (manning over time required to release personnel) 



Desired Manpower[Phase,Discipline]= 

MAX( DesiredAccomplisliingRate[Pliase, Discipline] / (Avg Design Rate[Phase.Discipline]\ 
*Adjust Rate[Phase]), Baseline Desired Manning[Phase,Discipline]) 

Manpower 
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Net NAVSEA= 

SUM(NAVSEA Phase[Phase!]) 
~ Manpower 



Contractor Experience Release Rate[Phase.Discipline]= 

IF TIffiN ELSE(Current Phase [Phase] =0. Contractor Experienced[Phase,Discipline]/Contractor Release 

Period\ 

,MIN(Contractor Exp Desired Release[Phase,Discipline]/Contractor Release PeriodContractor 

Experienced\ 

[Phase,Discipline] 

/Contractor Release Period)) 

~ Manpower/Month 



Schedule Shift [Concept, Discipline] = 

(Indicated Completion Datc[Concept,Discipline]-Desired Schedule[Concept.Discipline])\ 

/Time to Shift Schedule — | 

Schedule Shift[Preliminar\,Discipline]= 

MAX(Indicated Completion Date [ConccptDiscipline] -Desired Schedule[Concept,Disciphne\ 

],Indicated Completion Date[Preliminar\.Discipline]-Desired Schedule[Prelirninar\\Discipliiie\ 
])/Timc to Shift Schedule — | 

Schedule Shift[Contract,Disciplme]= 

MAX(Indicated Completion Date[Concept,Disciplme] -Desired Schedule[Concept,Discipline\ 

],MAX(Indicated Completion Date[Prcliminar\\Discipline]-Desired Schedule [T^eliniinar>\ 
.Disciphne], Indicated Completion Date 

[Contract.Discipline] -Desired Schedule[Contract,Discipline]))/Time to Shift Schedule\ 

Schedule Shift[Lead Ship,Disciplinc]= 

MAX(Indicated Completion Date[Concept,Disciphne] -Desired Scliedulc[Concept.Discipline\ 

],MAX(Indicated Completion Date[Preliminar>, Discipline] -Desired Schedule[Preliminar>\ 
,Discipline],MAX(Indicated Completion Date 

[Coiitract.Discipline]-Desired Schedule[Contract,Discipline] Jndicated Completion Date\ 

[Lead Ship.Disciphne] -Desired SchedulefLead Ship,Discipline])))/Time to Sliift Schedule\ 

Schedule Shift[Maiiufacturing,Discipline]= 

MAX(Indicated Completion Date[Concept,Discipline]-Desired Schedule[Concept,Discipline\ 

],MAX(Indicated Completion Date[Preliminar> ,Discipliiie]-Desired Schedule [Preliminar\\ 
,Discipline],MAX(Indicated Completion Date 

[Contract,Discipline] -Desired Schedule [Contract,Discipline],MAX(Indicated Completion Date\ 

[Lead Ship,Discipline]-Desired Schedule[Lead Ship,Discipline], Indicated Completion Date\ 
[Manufacturing, Discipline 

]-Dcsircd Schedule[Manufacturing,Discipline]))))/Timc to Sliift Schedule 

~ Month/Moiith 

~ The shift of design schedule is the indicated completion date o\’er tlie \ 
time required to initiate the full time shift... note that each phase date \ 
is shift by preceding phase schedule sliifts as well 



Percent Hiase Complete[Phase]= 

Total Approved Tasks[Phase]/SUM(Phase Tasks[Phase,Discipline!]) 

~ Dimensionless 

Tlie Percent Completion of the current phase is the ratio of the total \ 
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approved tasks to the total phases tasks initially required to be done 



Current Contract Fee[Phase]= 

Percentage of RFP Contracts[Phase]*K(l -Percentage of RFP Contracts[Phase])*l , 1 
-- Dimensionless 

Tlie current contract fee represents the effective cost of contractors as a \ 
function of those contracted at RFP rate (100% cost) and those on current \ 
NAVSEA contracts (additional 10% overhead to cost) 



Ov’ertime[Phase,Discipline]= 

MIN(Maxiniimi Overtime,Effect of Schedule Gap on OvertimcfPhase, Discipline] *Overtime A 
(Indicated Overtime Required[Phase,Discipline])) 

~ fraction 

~ Tlie current assigned overtime is the maximum of maximum ov ertime to assign \ 
and the overtime profile (assignment schedule) for a given indicated \ 
ov ertime requirement 



Effect of NAVSEA Percent f( 

[(0,0)-(U)].(0,l),(0.5,l),(075, 0.75), (1,0)) 
-- Dimensionless 



Effective Nevv[Phase.Discipline]= 

Contractor Nevv[Phasc.Discipline]*Ovcrtime[Phase, Discipline] 
- Manpower 

New Contractors times the overtime assigned 



Prob Discovery' by Phase[Phase]= 

0.4.0.37,0.3,0.23,0.2 
-- Dimensionless 

-- The probability of discovery- of an error increases for each phase as more \ 
individuals are involved with tlic project and increasing detail is examined 



Prob Defect Discovery [Phase,Disciplinc]= 

Effect of Errors on Discoveiy'[Phasc.Discipline]*Prob Discoveiy- by Phase[Phase] 

~ Tasks/Tasks 

- Probability of Discovery by Design Phase times the changing probability of \ 
discovery (Effect of Errors on Discovery ) as the total errors for the \ 
current phase increases 



Comp Rate f[Phase.Discipline]= 

MlN(WIP[Phasc,Discipline]^in Comp Pcriod[Phase.Discipline].Effective Personnel Le\ el\ 
[Phase,Discipline]*Net Productivity' Rate 
[Phase.Discipline]) 

~ Tasks/Month 

- Tlie average completion rate for the WIP remaining in each discipline \ 

during each phase is the lesser of time limited completion (WIP/minimum \ 
period to complete) and resource limited completion (personnel av ailable \ 
times net rate of productiv ity per person) 
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Review Rate[Phase,Discipline]= 

Re\iew Phase[Phase]*Completed[Phase,Discipline]/Review Period[Phase] 

~ Tasks/Month 

-- The rate of NAVSEA Review of Tasks is the completed tasks over the time \ 
required to review a task... note that this assumes task review is \ 
continuous (more hkely this is not the case... and leads to the \ 
possibility of draining completed tasks prior to proper iteration through \ 
the feedback matrix... 



Review Ratio Actual [Phase] = 

(SUM(Completed[Phase,Discipline!])+SUIVl(Approved[Phase,Discipline!])+SUM(Revie\v[Phase\ 
,Discipline!]))/SUM(Initial Tasks[Phase,Discipline!]) 

~ Dimensionless 

~ The Ratio of total tasks available for or already approved to the total \ 
intial tasks is the total of tasks released at review and those residing \ 
as Approved divided by the initial tasks. ..by phase. 



Review^ Ratio Dcsired[Phase]= 
0 . 8 , 0 . 9 , 0 . 95 , 0 . 5 , 0.5 
~ Tasks/Tasks 



Re\ iew Error Rate f[Phase,Discipline]= 

Adj Prob Defect[Phase,Discipline]*Prob Defect Discovery [Phase,Discipline]*(Rcview[Phase\ 
,Disciphne]/Time to Detect Errors [Phase]) 

~ Tasks/Month 



Review Phase[Pliase]= 

Review Phase Effect f(Revie\v Ratio Actual[Phase]/Review Ratio Desired[Phase]) 
~ Dimensionless 

~ Tlie approval phase is active ( 1) for actual to desired ratios greater than \ 

1 and inactive (0) for ratios less than 1 



Review Phase Effect f( 

[( 0 , 0 )-( 2 , 1 )],( 0 , 0 ),( 0 . 537764 , 0 . 092 1 053 ),( 0 . 7734 1 4 . 0 . 25 ),( 0 . 954683 , 0 . 820 175 ),( 1 , 1 ),(\ 

2 , 1 )) 

~ Dimensionless 

~ The approval Phase Effect Function compares the ratio of Approval Ratio \ 
Actual to Desired for net ratios greater than 1, the approv al pliase is \ 
active (1) for ratio less than I the approval phase is not active (0)\!\! 



Review Phase Nct= 

SUM(Review Phase[Pliase!]) 
~ Dimensionless 



Internal Error Rate f|Phase,Discipline]= 

Adj Prob Defect[Phase,Discipline]*Prob Defect Discovery [Phase.Discipline]*(Completed\ 
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[Pliasc,Discipline]/Timc to Detect Errors [Phase]) 
Tasks/Month 



EffectOfScheduleGapOnProductivity[Phase,Discipline]= 

EffectQTScheduJeGapOnProductivitv' f(Schedule Gap[Phase,Discipline\ 

]) 

-- dninl 



Adj Prob Defect[Phase,Discipline]= 

Prob Defect by Phasc[Phase]*Effect of Errors on Defects [Phase.Discipline] 
~ Tasks/Tasks 



NAVSEA Experienccd[Phasc,Disciplme]= INTEG ( 

NAVSEA Experience Gain Rate[Phase,Disciplinc]-NAVSEA Experienced Release Rate[PhaseA 
Discipline], 

0 ) 

~ Manpower 

~ The accumulation of NAVSEA personnel with direct experience with the \ 
current design Project is 0 plus the rate of experience gain less the \ 
release rate of experienced personnel from the project 



NAVSEA Available[Phase,Discipline]= INTEG ( 

NAVSEA New Release Rate[Phase,Disciplinc]+NAVSEA Experienced Release Rate[Pliase.Discipline\ 
]-NAVSEA Assign Rate[Phasc.Discipline], 

NAVSEA Baseline Persomicl[Phase,Discipline]) 

~ Manpower 



Effect of Errors on Dcfects[Phase.Discipline]= 

Effect of Errors on Defects f(Errors Discovered|Phase,Discipline]/lnitial Tasks[Phase\ 
.Disciplme]) 

~ Dimensionless 



Effect of Errors on Defects f( 

[(0,())-(l,l)],(0,lX(0.001,0.9)A0.01,0.8)A0.1,0.5).(0.247734,0.()745614)Al,0)) 
~ Dimensionless 



Effect of Errors on Discover\ [Phase,Disciplme]= 

Effect of Errors on Discovery^ f(Errors Disco\ ered[Phase.Disciplme]/Initial Tasks[Phase\ 
,Discipline]) 

~ Dimensionless 



NAVSEA Experience Gain Ratc[Phase,Disciphne]= 

NAVSEA Ncw[Phase,Discipline]/NAVSE A Experience Gain Period[Phase] 

-- Manpower/Montli 

-- The rate of transfer of persoimel from new' to project to experienced witli \ 
tlie project is tlie number of personnel o\ er the average time to acquire \ 
experience 
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i 






Error Discoverv Rate[Phase,Discipline]= 

Internal Error Rate[Phase,Discipline]+Review Error Rate[Phase.Discipline] 
-- Tasks/Month 



NAVSEA New[Phase,Discipline]= INTEG ( 

NAVSEA Assign Rate[Phase,Discipline]-NAVSEA Experience Gain Rate[Phase, Discipline] -NAVSEA 
New Release Rate\ 

[Phase^Discipline] 

0) 

~ Manpower 



Prob Defect bv Phase[Phase]= 

0 . 2 . 0 ' 19,0. 15.0. 11.0.1 
~ Dimensionless 

~ Probability of a defect will change with each phase due to increasing \ 
individuals and detail 



Total Errors per Phase[Phase]= 

SUM(Errors Discovered[Phase, Discipline ! ] ) 
~ Tasks 



Effect of Errors on Discover>' f( 

[(0,0)-(l.l)],(0.1X(6.001,0.9).(0.0L0.8).(0.1,0.5),(0.5,0.1X(k0)) 
~ Dimensionless 



Errors Discovered[Phase.Discipline]= INTEG ( 
Error Discoveiw' RatefPhase.Discipline]. 
0 ) 

~ Tasks 



Indicated CKertiine Required[Phase.Disciphne]= 

IF THEN ELSE(Personnel Assigned[Phase,Discipline]<=0. Adjusted Desired Manpower[Phase\ 
,Discipline]/Man, Adjusted Desired Manpower 
[Phase.Discipline]/Personnel Assigned[Phase.Disciplinej) 

~ Dimensionless 



Man= 



Manpower 

The unit for a single person 



Effect of Personnel Level on Productivit> [Phase, Discipline]= 

Effect of Persomiel Level on Productivity f(Personnel Assigned[Phase.Discipline]/Man\ 

) 
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Dimensionless 

Described in literature as ’’communication o\erhead”, mcreased levels of \ 
personnel assigned to a project can adversely effect productiviw from the \ 
standpoint of required personnel interaction, and down time for meetings. \ 
etc... 



Design Spiral Rate[Phase,Discipline]= 

Feedback FractionfPhase]*MIN(Completed[Phase,Discipline]/TIME STEP,MAX(Comp Rate[Phase\ 
,Al]*Design Spiral Matrix 
[Al, Discipline 

],MAX(Comp Rate[Phase,A2]*Design Spiral Matrix[A2,Discipline],MAX(Comp Rate[Phase,A3\ 
]*Design Spiral Matrix[A3,Discipline],MAX(Comp Rate 
[Phase,Bi]*Design Spiral Matrix[Bl, Discipline], MAX(Comp Rate[Phase,B2]*Design Spiral Matrix\ 
[B2,Discipline].MAX(Comp Rate[Phase,B3 

] 

*Design Spiral Matrix[B3, Discipline], NLAX(Comp Rate [Phase, B4]*Design Spiral Matrix[B4\ 
,Discipline],MAX(Comp Rate[Phase,B5]*Design Spiral Vlatrix 
[B5,Discipline],MAX(Comp RatePhase.Cl]*Design Spiral MatrixfCl, Discipline], MAX(Comp Rate\ 
[Phase,C2]*Design Spiral Matrix[C2, Discipline 

],MAX(Comp Rate[Phase,C3|*Design Spiral Matnx[C3,Discipline],MAX(Comp Rate[Pliase,C4\ 
]*Design Spiral Matrix[C4,Discipline],MAX(Comp Rate 
[Phase,C5]*Design Spiral Matrix[C5, Discipline], MAX(Comp Rate[Phase,C6]*Design Spiral Matrix\ 
[C6,Discipline],MAX(Comp Rate [Phase, C7 

] 

*Design Spiral Matrix[C7,Discipline],MAX(Comp Rate[Phase,Dl]*Design Spiral Matrix[Di\ 
.Discipline] ,MAX(Comp Rate[Phase,D2]*Design Spiral Matrix 
[D2.Discipline],MAX(Comp Rate[Phase,D3]*Design Spiral Matrix [D3. Discipline], MAX(Comp Rate\ 
[Phase,D4]*Design Spiral Matrix[D4,Discipline 

],MAX(CompRate[Phase,D5]*Design Spiral Matrix[D5,Discipline],MAX(Comp Rate[Phase.El\ 
]*Design Spiral MatrLx[El,Discipline].MAX(Comp Rate 
[Phase,E2]*Design Spiral Matrix [E2, Discipline], Comp Rate[Phase.Fl]*Design Spiral Matrix\ 
[Fl.Discipline]))))))))))))))))))))))) 

-- Tasks/IVIontli 

-- Design feedback (due to concurrent design assumptions inherent to the \ 

Naval Design Process) is the fraction of impacted design tasks (Feedback \ 
fraction) times llie minimum of completed tasks rate constraint (completed \ 
over design phase time measure.. . one month) and the maximum "work \ 
interference" rate for the given discipline compared to the other 22 \ 
disciplines (Feedback matrix times the disciplines completion rate) 



Effect of Personnel Level on Producti\ it>’ f( 

[(0,0)-(100, l)],(0,l).(25.6798,()3;64912),(52.8701,0.894737),(80. 0604,0. 714912),(100,\ 
0.5)) 

-- Dimensionless 



Funding Period^ 
12 



Month 



Rescope Fraction [Phase]= 
0.05 
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Dimensionless 



Current Phase[Phase]= 

Current to Future Phase[Phase]*Current to Past Phase [Phase] *Effect of Percent Complete on Project End\ 
[Phase] 

Dimensionless 

~ To determine if a design phase is a Current Pliase (equals 1), multiply the \ 

Current to Future Phase indicator times the Current to Past Phase \ 
indicator... if equals 0, the phase is not yet started (Current to Future \ 

Phase is 0) or already over (Current to Phase is 0) 



Percent Complete at Project End[Phase]= 
0.8,0.9,0.9,0.95,0.95 
~ Dimensionless 



Effect of Percent Complete on Project End f( 
[(0,0HU)],(0,1),(0.999,1X(1.0)) 

~ Dimensionless 



Effect of Percent Complete on Project End[Phase]= 

Effect of Percent Complete on Project End f(Percent Phase Complete[Phase]/Percent Complete at Project 

End\ 

[Phase]) 

~ Dimensionless 



Internal Error Rate[Phase,Discipline]= 

Internal Error Rate f[Phase,Discipline] 

~ Tasks/Month 

~ The rate of internal Q/A and defective discovery is the probabiliK of a \ 
defect times the probability of discovering the defect times the minimum \ 
of tasks available for inspection (completed over the time to detect) and \ 
the inspector constraint (QA constraint) 



Max Indicated Completion Date[Phase]= 

Indicated Completion Date[Phase,Al] 
~ Month 



NAVSEA Participation Nominal Percentage[Phase]= 

0.3,0.2,0.2,0. 1,0.1 
~ Dimensionless 

~ The desired manning level of NAVSEA relative to Contractors 



Personnel Assigned[Phase,Discipline]= 

NAVSEA Ne\v[Phase,Discipline]+Contractor Ne\v[Phase,Discipline]+Contractor Experienced\ 
[Phase, Discipline]+NAVSEA Experienced 
[Phase, Discipline] 

~ Manpower 
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Total personnel (NAVSEA and Contracted novice and experienced with the \ 
project) assigned to each discipline during a given time of each design \ 
phase 



Effect of Available Budget on NAVSEA Percent[Phase]= 

Effect of Available Budget on NAVSEA Percent f(Available to Desired Budget [Phase]) 
~ Dimensionless 



Approval Phase Net= 

SUM( Approval Phase [Phase!]) 
~ Dimensionless 



Planned Annual Funding[Phase]= 

3.2e+006. 1.5e+007, 1.62e+007,6.44e-K)07,2. 14e+007 
-- Dollars 

~ Initial Values determined from DDG-5 1 program (NAVSEA Ship Design \ 
Histories and Acquisition Budget results) 



GettingFatigued[Phase,Discipline]= 

(Overtime[Phase.Discipline] - Fatigue[Phase,Disciplinej) / TimeToGetFatigued 
fraction / Month 



Net Review[Phase]= 

SUVl(Review[Phase,Discipline!]) 
~ Tasks 



Effect of Approval Phase on Desired Manpow er f( 
[(0,0)-(U)],(0,l).(1.0.5)) 

~ Dimensionless 



Effect of Approval Phase on NAVSEA Percent [Phase ]= 

Effect of Appro\al Phase on NAVSEA Percent f(Approval Phase[Phasej) 
~ Dimensionless 



Effect of Appro\ al Phase on NAVSEA Percent f( 
[(0.0)-(1.2)],(0.1)T1.1.25)) 

-- Dimensionless 



Available to Desired Biidget[Phase]= 

IF THEN ELSE(Perceived Funding Requirements[Phase]<=0,4,A^■ailable Budget[Phase]/Perceived 
Funding Requirements\ 

[Phase]) 

~ Dimensionless 



Effect of Available Budget on Contractors f( 
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[(0,())-(8.10)],(0,0X(0.5,0.2).(0.75,0.5X(l,lX(2,4),(3.86707/).71053).(6,8),(8,8)) 
-- Manpower 

-- For available budget fractions near 0 (available is low) the fraction of \ 
contractors to be hired is directly proportional... as available to need is \ 
very large, more contractors will be hired up to a ver\^ large portion \ 
(overfunding) at which contractors are released\!\!\! 



Effective Personnel Level[Phase,Discipline]= 

(Contractor Experienced[Phase,Discipline]*PDY Contractor Experienced Factor+Contractor New 

[Phase, Discipline] *PDY Contractor New Factor+NAVSEA ExperiencedfPhase, Discipline] *PDY 
NAVSEA Experience Factor\ 

+NAVSEA New 

[Phase,Discipline]*PDY NAVSEA New Factor)*Overtime[Phase,Discipline] 

-- Manpower 

~ The effective personnel level is the sum of the effective number of \ 
personnel assigned (number of personnel times an experience factor) 

I 

CK ertime f( 

[(0,0)-(2,2.6)],(0. 1X(0. 175258, 1X(0. 4 17526, 1X(0.747423, 1),(L 1X(1.25.1),(L5, 1.2\ 
X(1.7,1.4X(1.8,1.6X(1.9,1.8),(2,2)) 
fraction 



Funding Gap[Pliase]= 

Perceived Funding Requirements[Phase]-A\'ailable Budget[Phase] 
~ Dollars 



Fiscal Reset= 

IF THEN ELSE(Fiscal Counter= 12. Fiscal Counter/TIME STEP,0) 
^ Dimensionless 



Net Approved[Phase]= 

SUM(Approved[Phase, Discipline!]) 
-- Tasks 



Change to Budget[Phase]= 

Current Phase[Pliase]*Fimding Gap[Phase]/Time to Change Budget 
~ Dollars/Month 



Net Completed[Phase]= 

SUM(Completed[Phase.Discipline!]) 
-- Tasks 



Contractors Phase[Phase]= 

SUM(Contractor Experienced[Phase,Discipline!])+SUM(Contractor New[Phase,Discipline!]\ 

) 

-- Manpower 
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Desired Manpower Phase [Phase] = 

SUM( Adjusted Desired Manpower[Phase.Discipline!j) 
~ Manpower 



NAVSEA Phase[Phase]= 

SUM(NAVSEA Experienced[Phase,Discipline!])+SU]VI(NAVSEA New [Phase. Disciphne!]) 
~ Manpower 



Contractor New Desired Release[Phase.Discipline]= 

IF THEN ELSE(-Manpower Shortage[Phase,Discipline]>0,MAX(0, ABS(Manpower Shortage [Phase\ 
,Discipline])*(l-NAVSEA Participation Adjusted Percentage [Phase,Discipline])*(ABS(l\ 
-Effect of Available Budget on Contractors[Phase]))),0) 

~ Manpower 

-- When personnel supluses exist, new contractors are released based as the \ 
fraction of manpower shortage desired as contractors 



Review Error Rate[Phase,Discipline]= 

Review Error Rate f[Phase.Discipline] 

~ Tasks/Month 

~ The rate of external Q/A and defective discover>' is the probability of a \ 
defect times the probability of discovering the defect times the minimum \ 
of tasks available for inspection (reviewed tasks over the time to detect) \ 
and the inspector constraint (QA constraint) 



Fiscal Counter Increase= 
1 



Dimensionless 



TimeToGetFatigued= 1 
~ Month 



Total Tasks[Phase]= 

Net Appro\ed[Phase]+Net Completed[Phase]+Net Review [Phase]+Net TB Coord[Phase]+Net TBD\ 
[Pliase]+Net WlP[Phase] 

~ Tasks 



Net TB Coord[Phase]= 

SUM(TBCoord[Phase,Discipline!]) 
~ Tasks 



Net TBD[Phase]= 

SUM(TBD[Phase.Discipline!j) 
~ Tasks 



Net WIP[Phase]= 
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SUM(WIP[Phase,Discipline!]) 

Tasks 



Fatigue[Phase,Discipline]= INTEG ( 

GettingFatigued[Phase,Discipline]. 

1 ) 

-- fraction 



Contractor New Assignments[Phasc,Discipline]= 

MAX(0,Effect of Available Budget on Contractors[Phase]*Manpower Shortage[Phase,Discipline\ 
]*(1-NAVSEA Participation Adjusted Percentage[Phase, Discipline])) 

Manpower 

Assignments will occur as the Manpower Shortage times the fraction of \ 
non-NAVSEA personnel required times a factor for budget available 



Effect of Available Budget on Conlractors[Phase]= 

Effect of Available Budget on Contractors f(Available to Desired Budget[Phase]) 
-- Manpower 



Fiscal Counter^ INTEG ( 

Fiscal Counter Increase-Fiscal Reset. 
0 ) 

~ Month 



Perceived Funding Requirements [Phase] = 

Total Contractors Assigned[Phase]*Contactor Cost*Current Phase[Phase]*ABS(Max Indicated 
Completion Date 

[Phase] -Time) 

~ Dollars 



Program Budget Rate[Phase]= 

Annual Fimding[Phase]*Current Phase[Phase]/Funding Period 
~ Dollars/Month 



Effect of Schedule Gap on Desired Manpower f( 

[(-40,0)-(40,10)],(-24,0.25).(-12.().5),(0,I),(3,k25),(12,2),(24.4)) 
~ Dimensionless 



Manpower Shortage[Pliase.Discipline]= 

Adjusted Desired Manpower[Phase,Discipline]-Personnel Assigned[Phase,Discipline] 
~ Manpower 



Contract Establishment Rate[Phase.Discipline]= 

Percentage of RFP Contracts[Phase]*Conlractor Pool[Phase,Discipline]/Contracting with RFP Rate\ 

[Phase,Discipline]+(l -Percentage of RFP Conlracts[Phase])*Contractor Pool [Phase, Disciplme\ 
]/Contracting with Existmg NAVSEA Contracts[Phase,Discipline] 
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Manpower/Month 



nimimurnCompletionDuration== 

1 



Month 



NAVSEA New Assigiinicnts[Phase,Discipline]= 

IF THEN ELSE(IVIanpo\ver Shortage[Phase,Discipline]>0, Manpower Shortage [Phase, Discipline\ 
]*NAVSEA Participation Adjusted Percentage[Phase,Discipline],0) 

~ Manpower 

~ For existing manpower shortage, the assigment of NAVSEA Personnel is the \ 
desired fraction of NAVSEA personnel times the required personnel 



Schedule Gap[Phase,Discipline]= 

Indicated Completion Date[Phase,Discipline] -Desired Schedule[Phase, Discipline] 
~ Month 



NAVSEA Exp Desired Release[Phase,Discipline]= 

IF THEN ELSE(NAVSEA New Desired Release[Phase,Discipline]<0,0,MAX(0,NAVSEA New Desired 

Release\ 

[Phase,Discipline] -NAVSEA New[Phase,Discipline])) 

Manpower 

-- When NAVSEA personnel are being released (NAVSEA New Desired Release is \ 
positive) experienced pcrsoimel are released only after all new personnel \ 
have been released 



DesiredAccomplishingRate[Phase,Discipline]= 

Perceived TBD[Phase,Discipline] / Remaining Design Phase Duration[Phase,Discipline] 
Tasks/Montli 



Remaining Design Phase Duration[Phase,Discipline]= 

MAX(minimumCompletionDuration, Desired Schedule [PIiasc.Discipline] - Time) 
~ Month 



NAVSEA New Desired Release[Phase.Discipline]= 

IF THEN ELSE(Maiipower Shortage[Phase,Discipline]>0,0,NAVSEA Participation Adjusted PercentageV 
[Phase.Disciplme]*ABS(Manpower Shortagc[Phasc. Discipline])) 

-- Manpower 



Percentage of RFP Contracts[Phase]= 

O.OLO.l, 0.2, 0.8,09 
-- Dimensionless 

The average fraction of total contracts which are RFPs \ ice existing \ 
NAVSEA contracts 



Effect of Schedule Gap on Desired Manpower[Phase,DiscipIine]= 
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Effect of Schedule Gap on Desired Manpower f(Schedule GapfPhase.Disciplinej) 
- Dimensionless 



Contractor Exp Desired Release[Phase,Discipline]= 

IF THEN ELSE(Contractor New Desired Release[Phase,Discipline]<0,O.MAX(0,Contractor New Desired 

Release\ 

[Phase,Discipline]-Contractor New[Phase,Discipline])) 

~ Manpower 



Contractor Release Peri ^d= 

1 

Montli 

Time required to release persomiel from the current project is 

I 

Contractors Available[Phase,Discipline]= INTEG ( 

Contractor Experience Release Ratc[Phase.Discipline]+Contractor New Released[Phase,Disciphne\ 
]-Contracted Assign Rate[Phase.Discipline]+Contract Establishment Rate[Phase,Discipline\ 

J. 

0 ) 

Manpower 



NAVSEA Experience Gain Period[Phase]= 

6 

~ Month 

~ Months required for individuals to acquire full working knowledge of the \ 
current project 



NAVSEA Release Period= 

1 

~ Montli 

~ Time required to release persomiel from the current project is 



Contractor New[Phase,Discipline]= INTEG ( 

Contracted Assign Rate[Phase.Discipline]-Contractor Experience Gain Rate[Phase.Discipline\ 
]-Contractor New Released[Phase,Discipline], 

0 ) 

-- Manpower 



EffectOfFatigueOnProductivity[Phase,Discipline]= 

EffectOfFatigueOnProducti\it>' f(Fatigue[Phase,Discipline]) 
~ dnml 



Contracting witli Existing NAVSEA Contracts[Phasc,Disciplinel= 

3 

Montli 

Months required to negotiate design work tluough existing NAVSEA Contracts 
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Contracting with RFP Rate[Phasc,Discipline]= 

18 

~ Month 

Months required to negotiate design work through new (RFP-request for \ 
proposals) contracts 



PDY Contractor Experienced Factor= 

1.1 

Dimensionless 

Contractor Experienced Personnel have an increased productiviK of 20% \ 
greater than that of an av erage designer 



Contractor Baseline Personnel[Phase,Discipline]= 

50 

-- Manpower 

~ NAVSEA Personnel available for assignment to the project by discipline and \ 
phase 



Contractor Experience Gain Period[Phase]= 

6 

Month 

~ Months required for individuals to acquire full working knowledge of the \ 
current project 



Contractor Experience Gain Rate[Phase,Discipline]= 

Contractor Nevv[Phase,Discipline]/Contractor Experience Gain Period[Phase] 

~ Manpovver/Montli 

~ The rate of transfer of persomiel from new to project to experienced with \ 
tlie project is the number of personnel over the average time to acquire \ 
experience 



Contractor Experienced[Phase, Discipline] = INTEG ( 

Contractor Experience Gain Rate[Phase.Discipline]-Contractor Experience Release Rate\ 
[Phase,Disciphne], 

0 ) 

~ Manpower 

~ The accumulation of NAVSEA personnel with direct experience with the \ 
current design Project is 0 plus the rate of experience gain less the \ 
release rate of experienced personnel from the project 



Indicated Completion Date[Phase.Discipline]= 

Current Phase[Phase]*(Time+IF THEN ELSE(Estimated Comp Rate[Phase,Discipline]<=0,60,\ 
Perceiv ed TBD[Phase.Disciphne]/Estimatcd Comp Rate 
[Phase,Disciplmc])) 

~ Month 

-- The estimated montlis to completion (per disepline per phase) is 0 if the \ 
phase is inactive (cither passed or not yet started) or is the TBD divided \ 
by the current rate of completion (personnel by personnel \ 
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productivity)... note at phase start, no personnel are assigned so an \ 
artificial estimate of 60 months is set. 



Contractor Pool[Phase,Discipline]= INTEG ( 

-Contract Establishment Rate(Phase,Discipline], 

Contractor Baseline Personnel(Phase,Discipline]) 

~ Manpower 

-- The pool of available contractors not available because contracts are not \ 
yet in place to allow their use 



PDY NAVSEA Experience Factor= 

1.1 

-- Dimensionless 

-- NAVSEA Experienced Personnel have an increased productivity of 20% greater \ 
tlian that of an a\ erage designer 



EffectOfFatigueOnProducth itv f( 

[(0.0)-(4.4)],(0,l),(l.il.01),(1.5,1.5).(2,2).^ 
-- drmil 



EffectOfScheduIeGapOnProductivity f( 

[(-10,0)-(10,1.75)],(-10,0.75),(0,0.9),(0.757732,0.904605),(U),(1.5,1.1),(2.50755A 
1 .25877).(3.83686, 1 .5274 1),(5, 1.684),( 10, 1 .75)) 

~ dmnl 



PDY NAVSEA New Factor= 

0.85 

-- Dimensionless 

~ NAVSEA Personnel new to the project have an increased productivity of 20% \ 
less than tliat of an a\ erage designer 



Estimated Comp RatelPhase,Discipline]= 

Avg Design Rate[Phase,Discipline]*Personnel Assigned[Phase,Discipline] 
~ Tasks/Month 



PDY Contractor New Factor= 

0.85 

~ Dimensionless 

~ Contractor Personnel new to the project have a producti\ity of 20% less \ 
than that of an average designer 



Spending Rate[Phase]= 

Total Contractors Assigned[Phase]*Contactor Cost 
~ Dollars/Month 



Desired Tasks to Assign[Phase,Discipline]= 
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Personnel Assigned[Phase,Disciplinel*Nct Productivity RatefPhasc, Discipline] *Design Phase Duration\ 
[Phase] 

~ Tasks 

~ The desired number of tasks to be assigned (by discipline) at a gh en time \ 
in a phase is the number of personnel available to work times the \ 
effective productivity of those personnel times montlis number of months \ 
into the project 



Design Phase Duration[Phase]= INTEG ( 

Design Phase Time Step[Phase], 

0 ) 

~ Month 

~ From the start of a design phase, how many months have passed... 



Design Phase Time Measure= 

1 

~ Month 

~ The basic measurement of design duration is 1 month of time 



Design Phase Time Step[Phasc]= 

Current Phase[Phase]*Dcsign Phase Time Measure/Design Phase Time Measure 
~ Month/Month 

~ The rate of increase of the design duration for a current phase (Current \ 

Pliase equals .1) is the current model time step over the basic measurement \ 
of time ( 1 month) 



Assign Rate[Phase.Disciplinc]= 

MIN(TBD[Phase, Discipline]/ Assign Period.Desircd Tasks to Assign[Phase,Discipline]/Assign Period\ 

) 

~ Tasks/Month 

~ Tlie assigmnent rate is tlic minimum of the assignable task constraint (TBD \ 
o\ er assignment period) and the desired task assignment constraint \ 

(desired tasks for assignment over the assigmnent period) 



Release Rate[Phase,Discipline]= 

Baseline Tasking[Phase,Discipline]*CuiTent Phase[Phase]/TIME STEP 
~ Tasks/Month 

~ At the commencement of a design phase, all baseline tasks arc released to \ 
TBD for assignmenet to designers, the release is dependent on the phase \ 
becoming active... time step is used to pro\ ide the release in a single \ 
pulse. 



Time to Detect Errors[Phase]= 

1 

~ Month 

-- Tlie minimmn time (by phase) required to detect an error in a task 



Current to Future Phase[Concept]= 
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Current to Future Phase[Prclimmar\ ]= 

Effect of Percent Phase Complete on Current to Future f(Percent Phase Complete[Concept\ 
]/Percent Phase Complete Desired[Concept]) — | 

Current to Future Pliase[Contract]= 

Effect of Percent Phase Complete on Current to Future f(Percent Phase Complete[Preliminarv\ 
]/Percent Phase Complete Dcsired[Prelmiinar> ]) ~| 

Current to Future Phase [Lead Ship]= 

Effect of Percent Phase Complete on Current to Futnre f(Percent Phase Complete[Contract\ 
]/Percent Phase Complete Desired[ Contract]) — | 

Current to Future Pliase[Manufactiiring]= 

Effect of Percent Pliase Complete on Current to FuUire f(Percent Phase Complete[Lead Ship\ 
j/Percent Phase Complete Desired[Lead Slupj) 

~ Dimensionless 

A design pliase can start (equals 1) when the previous design phase ratio \ 
of complcted/approved tasks to desired approved tasks is greater than 1 \ 

(by the Effect of Percent Phase Complete function.) 



WIP[Phase,Discipline]= INTEG ( 

Assign Rate[Phase,Discipline]+Coord Rate[Phase.Discipline]-Comp Rate[Phase,Discipline\ 

]. 

0 ) 

Tasks 

Work is progress is the number of tasks released from initial work (assign \ 
rate) plus the rework tasks returmng from coordination (coord rate) less \ 
the tasks completed by designers (comp rate) 



Net Comp Rate= 

SUM(Comp Rate[Concept.Disciplme!])+SUM(Comp Rate[Preliminaiy\Disciplme!])+SUM(Comp Rate\ 
[Contract, Discipline ! ] )+SUM( Comp Rate 
[Lead Shin.Disciplinc!])+SUM(Comp Rate[Manufacturing,Discipline!]) 

-- Tasks/Month 



Approi al Phase[Phase]= 

Appro\ul Phase Effect f( Approval Ratio Actual [Phase]/Appro\ al Ratio Dcsired[Phasej) 
~ Dimensionless 

~ Tlie approval phase is active ( 1 ) for actual to desired ratios greater than \ 

1 and inactive (0) for ratios less than 1 



Approval Pliase Effect f( 

[(0,0)-(2,l)],(0,0),(0.75,0),(0.999,0),(U),(2.1)) 

~ Dimensionless 

-- The approval Phase Effect Function compares the ratio of Appro\ al Ratio \ 
Actual to Desired for net ratios greater than 1. the approval phase is \ 
active (1) for ratio less than I the approval phase is not active (0) 



Approval Ratio Actual [Phase] = 

(SUM(Approved[Pliase,Discipliiie!])+SUM(Rcview[Phase,Disciphnc!]))/SUM(Initial Tasks[\ 
Phase.Discipline!]) 

-- Dimensionless 
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Tlie Ratio of total tasks a\ ailablc for or already' approved to the total \ 
intial tasks is tlie total of tasks released at review and those residing \ 
as Approved divided by the initial tasks . .by phase. 



Completed[Phase,Discipline]= INTEG ( 

+Comp RatefPhase.Discipline] -Review RatefPhase.Discipline] -Internal Error Rate[Phase\ 
.Discipline] -Design Spiral Rate[Phase. 

Discipline], 

0 ) 

~ Tasks 

~ Completed tasks are increased by the completion rate (Comp Rate) and \ 

decreased by release of tasks for NAVSEA review (Review Rate), rework of \ 
tasks due to concurrent feedback (Design Feedback Rate) and rework due to \ 
discovered errors (Defective Rate) 



Approve Rate[Phase.Discipline]= 

Approval Phase[Phase]*(Review [Phase.Discipline]/Approval PeriodfPhase]) 

^ Tasks/Month 

The rate of approval of tasks by DoN/DoD is the indicator that tasks \ 
lev els will support approv al process (Approval Phase equals 1) times the \ 
approv al rate (rev iewable tasks over the time required to review a task) 



Effect of Percent Phase Complete on Current to Future f( 
[(0,())-(2,l)].(0,0),(0.999,0),(l,l).(2.1)) 

~ Dimensionless 



Effect of Percent Phase Complete on Current to Past f( 
[(0,0)-(2,l)],((kl),(0.999,l).(l,0),(2,0)) 

~ Dimensionless 



Comp Rate[Phase,Discipline|= 

Comp Rate f[Phase,Discipline] 

~ Tasks/Month 

-- Tlie rate of completion of tasks is the av erage completion rate for tasks \ 
(...see resource sector for first order control of comp rate) 



TBD[Phase.Discipline]= INTEG ( 

-Assign Rate[Phase.Disciplme]+Release Rate[Phase,Discipline]+Rescope Rate[Phase,Discipline\ 

]. 

0 ) 

~ Tasks 

~ TBD is the quantity of tasks available for assigmnent increased by release \ 

(at phase start) and by rescoping of the project (design change \ 
introduction) by authorities, TBD is decreased by the assignment rate \ 

(assigning tasks to designers) 



Current to Past Phase[Concept]= 

Effect of Percent Phase Complete on Current to Past f(Current to Future Phase[PreliminarvA 
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])H 

Current to Past Phase[Preliminan ]= 

Effect of Percent Phase Complete on Current to Past f(Current to Future Phase [Contract 

])H 

Current to Past Phase[Contract]= 

Effect of Percent Phase Complete on Current to Past f(Current to Future Phase[Lead Ship\ 

])“l 

Current to Past Phase[Lead Ship]= 

IH 

Current to Past Phase[Manufacturing]= 

1 

-- Dimensionless 

- A phase is finished (equals 0) when tlie next design phase has achieved an \ 
inicator value (Current to Future Phase) for phase initiation (equals \ 
l)...acliieved through the table function Effect of Percent complete. 



TBCoord[Phase,Discipline]= INTEG ( 

+Design Spiral Rate[Phase.Discipline]-Coord Rate[Phase.Discipline]+Intemal Error Rate\ 
[Phase, Discipline]+Review^ Error Ratc[Phasc,Discipline], 

0 ) 

~ Tasks 

- The tasks requiring coordination prior to rework are increased by the \ 
tasks requiring rework (design feedback rate, defective rate and reject \ 
rate) less those tasks completing coordination and returning to the work \ 
cycle (coord rate) 



NAVSEA Baseline Personnel [Phase.Discipline]= 

7 

~ Manpower 

~ NAVSEA Personnel available for assignment to the project b>' discipline and \ 
phase 



Desired Schedule[Phase.Discipline]= INTEG ( 

Schedule Shift[Phase,Disciplme], 

Initial Schedule Projection [Phase]) 

~ Month 

~ The Desired Schedule is the initial schedule (months to phase completion \ 
from project start) estimate for each phase increased (or decreased) by \ 
the rate of schedule shift 



Perceived TBD[Phasc,Discipline]= 

Current Phase[Phase]*MAX(0,Imtial Tasks[Phasc.Discipline]*Percent Phase Complete Desired\ 
[Phase] -Perceived Completcd[Phase.E>iscipline]) 

Tasks 

The perceived TBD (for an active phase as detennined by the boolean \ 

Current Phase) is the maximum of 0 (floor value) and the tasks required to \ 
close the phase (initial tasks times transition ratio) minus the perceived \ 
completed tasks. 



Net Personnel Assigned^ 
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SUM(Nel Personnel Assigned PhasejPhase!]) 

~ Manpower 

- Net Personnel Assigned (by project) is tlie sum of personnel assigned by \ 
phase 



Annual Funding[Phase]= INTEG ( 

Change to Budget [Phase], 

Planned Annual Funding[Phase]) 
- Dollars 



Net Perceived TBD[Phase]= 

SUM(Perceived TBD[Phase. Discipline ! ]) 

-- Tasks 

Net Perceived TBD (by phase) is the sum of TBD by design discipline 



Effect of Available Budget on NAVSEA Percent f( 

[(0,0)-(l,l)]X0,l),(0.05,l),(0. 1,0.9), (0.2, 0.75), (1,0.75)) 
-- Dimensionless 



Available Budget[Phase]= INTEG ( 

-Spending Rate[Phase]+Program Budget Rate[Phase], 
1 ) 

~ Dollars 



Coord Rate f[Phase.Discipline]= 

TBCoord[Phase,Discipline]/Average Coord Period[Phase,Discipline] 

~ Tasks/Month 

~ Average Coordination Rate is the Tasks available for coordination over the \ 
time required to coordinate a task 



Coord Rate[Phase.Discipline]= 

Coord Rate f[Phase,Discipline] 

~ Tasks/Month 

The rate of coordination of tasks is the average coordination rate for \ 
tasks (...see resource sector for first order control of coord rate) 



Net Coord Rate [Phase] = 

SUM((Toord Rate flPhase.Disciplinel]) 
~ Tasks/Month 



Time to Change Budget= 
36 



Month 



Contactor Cost= 
6597 
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Dollars/(Month*Manpovver) 

The average monthly cost per contractor, including overhead costs, in FT96 \ 
dollars 



Spent Budget[Phase]= INTEG ( 
Spending Rate[Phase], 
0 ) 

- Dollars 



NAVSEA Assign Period= 
1 

~ Montli 



Time to Shift Schedule= 
24 

-- Month 



Perceived Completed[Phase,Discipline]= 

Revie\v[Phase,Discipline]+Completed[Phase,Discipline]+Approved[Phase,Discipline] 

Tasks 

-- Perceived completed is the number of tasks in review plus those awaiting \ 
re\iew (completed) plus those approved 



Contractor Assign Period[Phase]= 
1 



Montli 



Net Perceived Completed[Phase]= 

SUM(Perceived Completed[Phase,Discipline!]) 

~ Tasks 

~ Net perceie\ ed completed tasks (by phase) are the sum of all perceived \ 
completed tasks by design discipline 



Net Personnel Assigned Phase [Phase]= 

SUM(Personnel Assigned[Phase,Disciphne ! ] ) 

Manpower 

Net Current Personnel Assigned (by phase) is the sum of persoimel assigned \ 
by design discipline 



Step Down Time= 
0 



Month 



Pink Noise = INTEG(Change in Pink Noise, 0) 

-- Dimensionless 

~ Pink Noise is first-order autocorrelated noise. Pink noise provides a realistic \ 
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noise input to 

models in which the next random shock depends in part on the previous \ 
shocks. The user 

can specify the correlation time. The mean is 0 and the standard deviation \ 
is specified 

by the user. 



Inputs 

MAX(Pink Noise,MIN(STEP(Step Height.Step Up Time)+ 

(Pulse C?uantity/TIME STEP)*PULSE(Pulse Time,TIME STEP)+ 

RAMP(Ramp Slope,Ram,p Start Time,Ramp End Time)+ 

Sine Amplitude*SIN(2*3. 14159*Time/Sine Period)+ 

STEP(l,Noise Start Time)*Pink Noise, 1-STEP( Step HeightStep Down Time))) 
-- Dimensionless 

~ Input is a dimensionless variable vviiich provides a variefy^ of test input patterns, \ 
including a step, 

pulse, sine wave, and random noise. 



Change in Pink Noise = (White Noise - Pink Noise)/Noise Correlation Time 
~ 1/Month 

-- Change in the pink noise value: Pink noise is a first order exponential smoothing \ 
delay of the white 
noise input. 



Sine Amplitude= 

1 

-- Dimensionless 

~ Amphtude of sine wave in customer orders (fraction of mean). 

I 

Sine Period= 

25 

~ Month 

~ Period of sine wav e in customer demand. Set initially to 50 weeks ( 1 \ 

vear). 

I 

Step Height^ 

1 

-- Dimensionless 

~ Height of step input to customor orders, as fraction of initial v alue. 



Pulse (Juantitv^ 

1 

~ Month 

-- The quantity to be injected to customer orders, as a fraction of tlie base value of \ 
Input. 

For example, to pulse in a quantify’ equal to 50% of tlic current value of \ 
input, set to 
.50. 
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Pulse Timc= 

62 

-- Month 

-- Time at vvliich the pulse in Input occurs. 



White Noise = Noise Standard Deviation*((24*Noise Correlation Time/TINIE STEP)'^0.5*(RANDOM 0 1\ 
0-0.5 

)) 

-- Dimensionless 

~ White noise input to the pink noise process. 



Noise Correlation Time = 4 
~ Month 

~ The correlation time constant for Pink Noise. 



Ramp Slope=0 

~ 1 /Month 

Slope of the ramp input, as a fraction of the base value (per week). 



Ramp Start Time= 

0 

-- Month 

-- Start time for the ramp input. 



Ramp End Time=le+009 
~ Month 

~ End time for tlie ramp input. 

I 

Noise Standard Deviation= 

0.5 

~ Dimensionless 

Tlie standard deviation of the pink noise process. 

I 

Noise Start Time= 

0 

-- Month 

-- Start time for the random input. 



Step Up Time= 
0 



Month 

Time for the step input. 



Approved[Phase,DisciplineI= INTEG ( 
Approve Rate[Phase, Discipline], 
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0 ) 

Tasks 

The total tasks (by discipline) approv ed by DoN/DoD and considered remov ed \ 
from the phase 



Total Approv ed Tasks[Phase]= 

SUM( ApprovedjPhase.Discipline ! ] ) 

Tasks 

The total approved tasks for all disciplines in a single design phase 



Approval Period[Phase]= 

UJ, 0.125,0. 125 
~ Month 

The current time required to rev iew a task by DoN/DoD is considered 3 \ 
montlis 



Approv al Ratio Desired[PhaseJ= 
0.8, 0.9, 0.95,0.5,0.5 
Tasks/Tasks 



Revievv[Phasc,Discipline]= INTEG ( 

Review Ratc[Phase.Discipline] -Approv e Rate[Phase,Disciplinc]-Rcvievv Error Rate[Phase\ 
,Discipline], 

0 ) 

~ Tasks 

~ Tlie tasks reviewed by NAVSEA are increased by the rev iew rate and \ 

decreased by those tasks rejected to rework (errors discovered) and tliose \ 
design tasks provided to DoN/DoD for final approv al 



Baseline Tasking[Phase,Discipline]= INTEG ( 

-Release Rate[Phase,Disciplme]. 

Initial Tasks[Phase,Discipline]) 

Tasks 

~ Tlie Initial Stock of design tasks for tlie 23 design disciplines and 5 \ 

phases, the stock is drained to 0 at Uie commencement of each phase (tlie \ 
phase becomes active.) This stock initiates tlie model for a phase 



Percent Phase Complete Desired[Phase]= 
0.8, 0.9, 0.95, 0.75, 0.5 
~ Tasks/Tasks 



Pliase: 

Concept, Preliminarv , Contract, Lead Ship, Manufacturing 
~ Tasks/Tasks 



Assign Period= 
1 
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Month 

The average lime required to assign a task is 1 month 



Discipline: 

Ak A2, A3, Bl. B2, B3. B4. B5, Cl, C2. C3, C4, C5, C6, C7. Dl. D2, D3, D4, D5, El, \ 
E2,F1 



Feedback: 

Al, A2, A3, Bl, B2, B3, B4, B5, Cl, C2, C3, C4, C5, C6, C7, Dl, D2, D3, D4, D5, El, \ 
E2,F1 



Initial Tasks[Concept,Discipline]= 

8, 8, 12, 2, 1, 1, 4, 2, 4, 6, 2, 1, 2. 7, 5. 3, 2, 2, 2, 1, 3, 2, 3 — | 

Initial Tasks[Preliininar\,Discipline]= 

10, 8, 13,2, 3 / 2 , 5,4,4, 19,2, 1, 11, 15, 16, 8, 7.7, 12,7, 9, 5, 4 H 
Initial Tasks(Contract,Discipline]= 

13, 8, 13, 2, 4, 2, 5, 4, 4, 20, 2. 2, 1 1, 18, 16, 9, 8, 8, 14, 7, 10, 5, 6 H 
Initial Tasks[Lead Ship.Discipline]= 

41, 25, 39, 6, 14, 9, 15, 12, 12, 60. 6, 6, 33, 54. 54, 35, 24, 24, 42, 21. 30. 15, \ 

18 H 

Initial Tasks[Manufacturing,Discipline]= 

14, 9, 13, 2, 5, 3, 5, 4, 4, 20, 2, 2, 1 1, 18, 20, 12, 8, 8. 14, 7, 10. 5, 6 
~ Tasks 

-- The baseline number of total deliverable tasks for each of the 23 design \ 
disciplines for each of the five design phases... values determined from \ 
DDG-51 Design Histories and evaluations from the La\ erglietta Design Thesis 



Review Period[Phase]= 

0. 325.0.325.0.325.0.1.0.1 

-- Month 

-- Minimum time reqiured to review a single task 

I 

Design Spiral Malrix[Al,Discipline]= 

0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 . 0 . 0 , 0 . 0 , 0 . 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 . 0 ™ 

Design Spiral Matrix[A2.Discipline]= 

1.0, 1. 1, 1, 1, 1, 1, 1, 1, 1, 1. 1, 1. 1, 1, 1. 1, 1. 1, 1, 1, I'— 

Design Spiral Matrix[A3,Discipline]= 

1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1 ™ 

Design Spiral Matrix[Bl,Discipline]= 

1 , 1 , 0 , 0 , 0 , 1 , 1 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 . 0 , 0 . 0 . 0 

Design Spiral Matrix[B2.Disciplme]= 

1 , 1 , 0 , 1 , 0 , 1 . 0 , 0 . 0 , 0 , 0 , 0 , 0 , 0 . 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 , 0 — - 

Design Spiral Matrix[B3.Discipline]= 

1 . 1 . 0 , 0 , 1 , 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 , 1 — - 

Design Spiral Matrix[B4.Discipline]= 

1 , 1 , 0 , 0 , 0 , 0 , 0 , 1 , 1 , 1 , 0 , 0 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 0 ~ 

Design Spiral Matrix[B5,Discipline]= 

1 , 1 , 0 , 1 , 1 , 0 , 1 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 1 , 1 , 0 , 1 , 1 , 0 , 0 , 0 , 1 ™ 
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Design Spiral Matrix[Cl,Discipline]= 

1, 1, 0, (X 1, 1, 0, (X 0, 1. 1, 1, 1, L 1, 1, 1, h 1, 0, 0, 0, 1 H 
Design Spiral Matrix[C2,Discipline]= 

1, 1, (X 0, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1. 1, 1, 1. 1, 1. 1, 1, 1 H 
Design Spiral Malrix[C3,Discipline]= 

1, 1, 0, 0, 0, 0, L 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0. 0, 0, 0, 0, 0 — I 
Design Spiral Matnx[C4,Discipline]= 

1, 1, 0, 0, 0. 0, 1, 0, 0, 1, 0, 0, 0, I, 0, 0, 0, 0, 0, I, 1, 0, 0 H 

Design Spiral Matrix[C5,Discipline]= 

1, 1, 0, 1, 1. 1. 1. 0, 0, 1, 1, L 0, 1, L 1, 1, 1, 1, 0, 0, 0, 1 H 

Design Spiral Matxix[C6,Discipline]= 

1. 1. 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0. 0, 0, 1 H 

Design Spiral Matrix[C7,Discipline]= 

1, 1, 0, X X X X X 0. X 0, 0, 0, X 0, L X X X X X X 1 H 
Design Spiral Matrix[DXDiscipline]= 

X X 0, X X X X X 0, X 0, 0, 0, X 1, 0, X X X X 0, 0, I H 
Design Spiral Matrix[D2.Discipline]= 

X X 0, X X X X X 0, X X 0, X X X X 0. X X 0, 0. 0. 1 H 

Design Spiral Mairix[D3,Discipline]= 

X X 0, X X X X X 0, X 0, 0, 0, X X X X 0, X X X X 1 H 
Design Spiral Malrix[D4,Discipline]= 

X X 0, X X X X X 0, X 0. X X X. X X X X 0, X X X 1 H 
Design Spiral Matrix [D5,Discipline]= 

X X 0, X X X X X 0, X 0. 0, 0, X X X 0. X X 0, 0. 0. 1 H 
Design Spiral Malrix[EXDisciplinel= 

X X 0 , X X X X X 0 , X 0, 0 , 0 , X X X 0, X X 0 , 0 , X 1 H 
Design Spiral Matrix[E2,Discipline]= 

X X 0 . X X X X X 0 , X X 0 , 0 , X X x o, i, X o, x o, i h 

Design Spiral Matrix[FXDiscipline]= 

X X 0, 0, 0, 0, 0, 0, X X 0, 0, 0, X X X X X X X X X 0 
~ Tasks/Tasks 

-- The design spiral matrix (aka design structure matrix) represents the \ 
first order inpiit/output requirements associating one ship design \ 
discipline to another.,. a value of "0" indicates the discipline is not an \ 
input to tlie given element, ” 1 '* indicates a significant level of input to \ 
the element 



Min Comp Period [Phase,Discipline]= 

0.5 

~ Month 

~ Minimum period of time required to complete any given task regardless of 
the resources available is estimated to be one week (same for all tasks \ 
and all phases) 



Average Coord Period[Phase.Discipline]= 

1 

~ Month 

~ For tasks requiring coordination and personnel interaction, tliis is the \ 
average penod required to coordinate a task 



Feedback Fraction [Phase] = 
0.5 

~ Tasks/Tasks 



187 



